From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by dpdk.org (Postfix) with ESMTP id B2A712B92 for ; Wed, 18 Oct 2017 14:24:58 +0200 (CEST) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga105.fm.intel.com with ESMTP; 18 Oct 2017 05:24:57 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.43,396,1503385200"; d="scan'208";a="1232172488" Received: from bricha3-mobl3.ger.corp.intel.com ([10.237.221.32]) by fmsmga002.fm.intel.com with SMTP; 18 Oct 2017 05:24:55 -0700 Received: by (sSMTP sendmail emulation); Wed, 18 Oct 2017 13:24:54 +0100 Date: Wed, 18 Oct 2017 13:24:54 +0100 From: Bruce Richardson To: Luca Boccassi Cc: dev@dpdk.org, thomas@monjalon.net, olivier.matz@6wind.com, sergio.gonzalez.monroy@intel.com Message-ID: <20171018122453.GA5596@bricha3-MOBL3.ger.corp.intel.com> References: <20171017161220.59941-1-bruce.richardson@intel.com> <20171017161220.59941-2-bruce.richardson@intel.com> <1508263898.32437.1.camel@debian.org> <1508264229.32437.3.camel@debian.org> <20171018093548.GA15216@bricha3-MOBL3.ger.corp.intel.com> <20171018095149.GA14720@bricha3-MOBL3.ger.corp.intel.com> <1508321647.25747.4.camel@debian.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <1508321647.25747.4.camel@debian.org> Organization: Intel Research and Development Ireland Ltd. User-Agent: Mutt/1.9.1 (2017-09-22) Subject: Re: [dpdk-dev] [PATCH 1/8] build: add maths library to libs in pkg-config file X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Oct 2017 12:24:59 -0000 On Wed, Oct 18, 2017 at 11:14:07AM +0100, Luca Boccassi wrote: > On Wed, 2017-10-18 at 10:51 +0100, Bruce Richardson wrote: > > On Wed, Oct 18, 2017 at 10:35:48AM +0100, Bruce Richardson wrote: > > > On Tue, Oct 17, 2017 at 07:17:09PM +0100, Luca Boccassi wrote: > > > > On Tue, 2017-10-17 at 19:11 +0100, Luca Boccassi wrote: > > > > > On Tue, 2017-10-17 at 17:12 +0100, Bruce Richardson wrote: > > > > > > Since a number of libraries depend on the maths lib, as well > > > > > > as > > > > > > adding it > > > > > > to the project args, we also need to add it to the pkgconfig > > > > > > file > > > > > > args. > > > > > > > > > > > > Signed-off-by: Bruce Richardson > > > > > > --- > > > > > >  config/meson.build | 1 + > > > > > >  1 file changed, 1 insertion(+) > > > > > > > > > > > > diff --git a/config/meson.build b/config/meson.build > > > > > > index db68a08d4..542fea4de 100644 > > > > > > --- a/config/meson.build > > > > > > +++ b/config/meson.build > > > > > > @@ -35,6 +35,7 @@ dpdk_conf.set('RTE_MACHINE', machine) > > > > > >  add_project_arguments('-march=@0@'.format(machine), > > > > > > language: 'c') > > > > > >  # some libs depend on maths lib > > > > > >  add_project_link_arguments('-lm', language: 'c') > > > > > > +dpdk_extra_ldflags += '-lm' > > > > > >   > > > > > >  # add -include rte_config to cflags > > > > > >  add_project_arguments('-include', 'rte_config.h', language: > > > > > > 'c') > > > > > > > > > > This is for static builds, right? If so it should go into the > > > > > Libs.private section of the .pc file, so that it's only used > > > > > when > > > > > calling pkg-config --static --libs > > > > > > > > Bit of a brain fart - what I meant is, in order to have static > > > > builds > > > > work out of the box with pkg-config --static, -lm (and any other > > > > dependency used internally) could also be added to Libs.private > > > > in the > > > > .pc > > > > > > Does that not assume that both static and dynamic libs are > > > installed > > > side-by-side? In DPDK case, we will either build static libs or > > > shared > > > libs, but not both. If we require applications to use different > > > pkg-config commands depending on the type of DPDK build that was > > > done, > > > it makes things awkward for the apps. Right now by putting all libs > > > and > > > flags into the libs section of pkgconfig, and having the build > > > system > > > track whether it's static or dynamic and therefore what is actually > > > necessary, we end up in a case where apps can be built against DPDK > > > irrespective of the actual build type done. For this particular -lm > > > flag, for instance, it only appears in the .pc file for static > > > builds. > > > > > > See the patches for the sample app Makefiles. Not sure how that can > > > be > > > made to work if we use different pkg-config settings for different > > > build > > > types. > > > > > > Your input and suggestions here would be welcome. > > Yes that works nicely when the libraries are rebuilt locally - then it > can be chosen whether to build the static or dynamic ones. > > In the packaging case though, at least in Debian and Ubuntu (not sure > about RHEL/SUSE), we do ship both static and dynamic libraries at the > same time, following best practices. So we'd have to choose and either > cause applications linking dynamically to over-link (which is what we > currently do in Debian/Ubuntu and many developers really don't like > that) or to cause applications that use the static libraries to have to > manually add the missing flags. > > From what I can see, the most common workflow for applications that > want to do static builds when using packaged libraries is to use the -- > static flag of pkgconfig. > This has the advantage of being a ""standardised"" workflow, expected > to work across any dependency, not just DPDK. Of course that's not > always the case, but one can dream :-) > > If you prefer to optimise for the local build workflow that's fine, we > can patch it in the distro, it's not too much overhead (I need to do it > anyway for the old build system at some point). > > > > > +Thomas, Olivier, Sergio to get more input > > > > Thinking about it some more, is there any reason why we can't or > > shouldn't do both static and dynamic libs in all builds, and then let > > apps use pkg-config to determine what they want to link against? It > > wouldn't be a massive change to the new build system to do that, I > > think. > > > > /Bruce > > Yes that would be ideal! Right now in Debian/Ubuntu we have to build > twice, doubling the required time unfortunately. > > In theory the same objects could be packed into .ar and .so but sadly > Meson doesn't support that yet like autotools/cmake do: > > https://github.com/mesonbuild/meson/issues/484 > > (please do add some feedback there as developers!) > > It looks like it could be possible with some extensive hacking, not > sure if it would be worth it. > Actually, I think it's workable using extract_objects. Build the static lib first, then extract_all_objects() and then use those to build the .so. I can prototype it very easily by changing lib/meson.build and see what happens. /Bruce