All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Monjalon <thomas@monjalon.net>
To: Bruce Richardson <bruce.richardson@intel.com>
Cc: dev@dpdk.org, david.marchand@redhat.com
Subject: Re: [dpdk-dev] [PATCH] devtools/test-meson-builds: allow custom set of examples
Date: Tue, 10 Nov 2020 15:36:14 +0100	[thread overview]
Message-ID: <4260818.77I6s4UBcg@thomas> (raw)
In-Reply-To: <20201110141900.GH1641@bricha3-MOBL.ger.corp.intel.com>

10/11/2020 15:19, Bruce Richardson:
> On Tue, Nov 10, 2020 at 02:53:03PM +0100, Thomas Monjalon wrote:
> > 10/11/2020 14:19, Bruce Richardson:
> > > On Tue, Nov 10, 2020 at 02:04:21PM +0100, Thomas Monjalon wrote:
> > > > 10/11/2020 12:34, Bruce Richardson:
> > > > > On Tue, Nov 10, 2020 at 12:25:13PM +0100, Thomas Monjalon wrote:
> > > > > > 10/11/2020 11:08, Bruce Richardson:
> > > > > > > On Mon, Nov 09, 2020 at 08:26:10PM +0100, Thomas Monjalon wrote:
> > > > > > > > 09/11/2020 19:02, Bruce Richardson:
> > > > > > > > > On Mon, Nov 09, 2020 at 06:09:51PM +0100, Thomas Monjalon wrote:
> > > > > > > > > > 27/10/2020 18:38, Bruce Richardson:
> > > > > > > > > > > To test the installation process of DPDK using "ninja install"
> > > > > > > > > > > test-meson-builds.sh builds a subset of the examples using "make".
> > > > > > > > > > > To allow more flexibility for people testing, allow the set of
> > > > > > > > > > > examples chosen for this make test to be overridden using variable
> > > > > > > > > > > "DPDK_BUILD_TEST_EXAMPLES" in the environment.
> > > > > > > > > > > 
> > > > > > > > > > > Since a number of example apps link against drivers directly even
> > > > > > > > > > > for shared builds, we need to ensure that LD_LIBRARY_PATH points to
> > > > > > > > > > > the main DPDK lib folder so any dependencies of those drivers can
> > > > > > > > > > > be found e.g. that the PCI/vdev bus driver .so is found. [All
> > > > > > > > > > > drivers are symlinked from drivers dir back to lib dir on install,
> > > > > > > > > > > so only one dir rather than two is needed in the path.]
> > > > > > > > > > [...]
> > > > > > > > > > > +libdir=$(dirname $(find $DESTDIR -name librte_eal.so)) +export
> > > > > > > > > > > LD_LIBRARY_PATH=$libdir:$LD_LIBRARY_PATH
> > > > > > > > > > 
> > > > > > > > > > I don't get why libdir is required for some examples, and not for
> > > > > > > > > > others? The pkg-config file is not enough?
> > > > > > > > > > 
> > > > > > > > > 
> > > > > > > > > It's only needed for examples that link against drivers directly. 
> > > > > > > > > 
> > > > > > > > > I believe it's needed in those cases, because app linker flags
> > > > > > > > > (including e.g. -lrte_pmd_bond) occur before the pkg-config flags,
> > > > > > > > > which means that the linker at that point does not have the path to
> > > > > > > > > find the dependencies of the driver. [In a normal build, this wouldn't
> > > > > > > > > be necessary because the library directory would be a standard path]
> > > > > > > > 
> > > > > > > > If it's just a matter of ordering, it would be a better example to fix
> > > > > > > > the ordering in the Makefile, isn't it?
> > > > > > > > 
> > > > > > > 
> > > > > > > I thought about that, but it seems strange to have the DPDK linker flags
> > > > > > > appear before the application specific flags. The general style is to have
> > > > > > > the apps own linker flags apply first, and then the list of dependencies,
> > > > > > > so that any app linker flags take precedence. The other option is to have
> > > > > > > two separate LDFLAG variables for the app, one for before pkg-config flags
> > > > > > > and the other afterwards, but that is an untidy solution.
> > > > > > > 
> > > > > > > Therefore, I think it's better to keep the ordering in the examples as-is
> > > > > > > and just set the library path in the script. It's only a single extra
> > > > > > > assignment that is necessary because we are installing to a non-standard
> > > > > > > path using DESTDIR.
> > > > > > 
> > > > > > It is OK to add LD_LIBRARY_PATH in test-meson-builds.sh because
> > > > > > DPDK is "installed" with a DESTDIR prefix.
> > > > > > 
> > > > > > But this change is unrelated to test more examples,
> > > > > > it is a general fix for examples compilation.
> > > > > > The thing I'm missing, as I said above,
> > > > > > "why libdir is required for some examples, and not for others?"
> > > > > > I feel something wrong made linking work where it should not.
> > > > > > 
> > > > > 
> > > > > As I explained above, libdir is required for examples that link directly
> > > > > against DPDK drivers in shared builds. There are only a few examples that
> > > > > do so, which is why the majority worked fine, and why this was not needed
> > > > > before.
> > > > 
> > > > Sorry I don't understand how we link other libraries without LD_LIBRARY_PATH.
> > > > Where the library path was taken from before this change?
> > > > 
> > > 
> > > pkg-config outputs the library path via -L flag for all the other
> > > libraries, which is why they are picked up.  Right now the flags passed are
> > > (in the case of the bonding example app):
> > > 
> > > 	LDFLAGS += -lrte_net_bond
> > > 	...
> > > 	LDFLAGS_SHARED = $(shell $(PKGCONF) --libs libdpdk)
> > > 	...
> > > 	build/$(APP)-shared: $(SRCS-y) Makefile $(PC_FILE) | build
> > > 		$(CC) $(CFLAGS) $(SRCS-y) -o $@ $(LDFLAGS) $(LDFLAGS_SHARED)
> > > 
> > > which resolves to (roughly): 
> > > "-lrte_net_bond -L/path/to/dpdk/libs -lrte_ethdev ..."
> > 
> > This is the part I still don't understand.
> > How it can resolve to path including DESTDIR?
> > In my test, it resolves to -L/usr/local/lib so it cannot work.
> > 
> It's the --define-prefix parameter we pass to pkg-config that does the
> trick.
> 
> 	$ export PKG_CONFIG_LIBDIR=$(pwd)/usr/local/lib/pkgconfig:/usr/lib/x86_64-linux-gnu/pkgconfig
> 
> 	$ pkg-config --libs-only-L libdpdk
> 	-L/usr/local/lib -L/usr/lib/x86_64-linux-gnu
> 
> 	$ pkg-config --define-prefix --libs-only-L libdpdk
> 	-L/home/bruce/dpdk.org/__BUILDS/build-x86-default/install/usr/local/lib -L/usr/lib/lib/x86_64-linux-gnu
> 
> This is done in test-meson-builds right before we call make for each
> example:
> 
> 	# if pkg-config defines the necessary flags, test building some examples
> 	if pkg-config --define-prefix libdpdk >/dev/null 2>&1; then
> 		export PKGCONF="pkg-config --define-prefix"
> 		...
> 	fi

Yes this is what David suggested to me,
but it doesn't work well for me (while test-meson-builds.sh works):

PKG_CONFIG_PATH=../dpdk-build/build-x86-default/meson-private \
pkg-config --define-prefix --libs-only-L libdpdk
-L/usr/local/lib

Oh! I am testing on the build directory instead of installed one.

PKG_CONFIG_PATH=../dpdk-build/build-x86-default/install/usr/local/lib/pkgconfig \
pkg-config --define-prefix --libs-only-L libdpdk
-L../dpdk-build/build-x86-default/install/usr/local/lib

Good :)
Now THE question: what is the difference between these two .pc files?



  reply	other threads:[~2020-11-10 14:36 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-10-27 17:38 [dpdk-dev] [PATCH] devtools/test-meson-builds: allow custom set of examples Bruce Richardson
2020-11-09 10:01 ` David Marchand
2020-11-12 15:40   ` Thomas Monjalon
2020-11-09 17:09 ` Thomas Monjalon
2020-11-09 18:02   ` Bruce Richardson
2020-11-09 19:26     ` Thomas Monjalon
2020-11-10 10:08       ` Bruce Richardson
2020-11-10 11:25         ` Thomas Monjalon
2020-11-10 11:34           ` Bruce Richardson
2020-11-10 13:04             ` Thomas Monjalon
2020-11-10 13:19               ` Bruce Richardson
2020-11-10 13:53                 ` Thomas Monjalon
2020-11-10 14:19                   ` Bruce Richardson
2020-11-10 14:36                     ` Thomas Monjalon [this message]
2020-11-12 14:40                       ` David Marchand

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4260818.77I6s4UBcg@thomas \
    --to=thomas@monjalon.net \
    --cc=bruce.richardson@intel.com \
    --cc=david.marchand@redhat.com \
    --cc=dev@dpdk.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.