From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <dev-bounces@dpdk.org> Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 7D26BA0526; Tue, 10 Nov 2020 11:09:02 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id B9B06F90; Tue, 10 Nov 2020 11:09:00 +0100 (CET) Received: from mga18.intel.com (mga18.intel.com [134.134.136.126]) by dpdk.org (Postfix) with ESMTP id D859CF64 for <dev@dpdk.org>; Tue, 10 Nov 2020 11:08:58 +0100 (CET) IronPort-SDR: kD4E7rlg0ygQ1RuweXhLEvO9PT+xK4BoxdDvRF5SCSLTdmv09DCe6SrCek7o3bXC7NWVeLmBVy zzZayyzIXgvA== X-IronPort-AV: E=McAfee;i="6000,8403,9800"; a="157730161" X-IronPort-AV: E=Sophos;i="5.77,466,1596524400"; d="scan'208";a="157730161" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga004.jf.intel.com ([10.7.209.38]) by orsmga106.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 10 Nov 2020 02:08:57 -0800 IronPort-SDR: Tsyuqn3iBPCzen7Y3FO+P/0brx0g6GxGu1K6mm6x2amD1hZL0NfSTE9Xlb5M2MS/rT3mC4p6ng tg5ujLHzI63w== X-IronPort-AV: E=Sophos;i="5.77,466,1596524400"; d="scan'208";a="473368999" Received: from bricha3-mobl.ger.corp.intel.com ([10.213.241.186]) by orsmga004-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA; 10 Nov 2020 02:08:56 -0800 Date: Tue, 10 Nov 2020 10:08:51 +0000 From: Bruce Richardson <bruce.richardson@intel.com> To: Thomas Monjalon <thomas@monjalon.net> Cc: dev@dpdk.org, david.marchand@redhat.com Message-ID: <20201110100851.GA1641@bricha3-MOBL.ger.corp.intel.com> References: <20201027173836.891184-1-bruce.richardson@intel.com> <3123472.p7xLvF2YS7@thomas> <20201109180216.GM831@bricha3-MOBL.ger.corp.intel.com> <5825181.Lnf5Olbaf0@thomas> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5825181.Lnf5Olbaf0@thomas> Subject: Re: [dpdk-dev] [PATCH] devtools/test-meson-builds: allow custom set of examples X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions <dev.dpdk.org> List-Unsubscribe: <https://mails.dpdk.org/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://mails.dpdk.org/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <https://mails.dpdk.org/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> Errors-To: dev-bounces@dpdk.org Sender: "dev" <dev-bounces@dpdk.org> 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. /Bruce