From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr0-f195.google.com (mail-wr0-f195.google.com [209.85.128.195]) by dpdk.org (Postfix) with ESMTP id 985401B226 for ; Wed, 18 Oct 2017 17:28:37 +0200 (CEST) Received: by mail-wr0-f195.google.com with SMTP id j14so5447825wre.8 for ; Wed, 18 Oct 2017 08:28:37 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:message-id:subject:from:to:cc:date:in-reply-to :references:content-transfer-encoding:mime-version; bh=72T25N7bTMg1um5jo2nknX990TXLwmV1fo6VFT80RmQ=; b=iC7y8oUaEz0EDTGFPBI/xe2lu+wcWEJcFICpVGU1hQZSqQS/2ytTshqQZrqsgswt3J mVOgPngFB0SL3/oEAcvI1DHVyCJGZy84KSgEZ7iT1UOj79RME86tISLmwhGQ+1zVYcDU ZrAJrS+/Hm3vbg6HDrjxUQuIRgcgiRpeN6avEA82M5NZfGbGR3jl8WC8KeI4wOYDHBWl YhpCsoiXwaFsZTe4/wfaexaiPQsxTbPrFupqr7z+oSyPhRty903Y3IzklH35tNtqpkU5 lSODKCVlvCVDUXZnTsSMAX52k545HsYl4brvhU/DY8U//vPFGy7fkfmcC0UzuNp0pVmc +agw== X-Gm-Message-State: AMCzsaV5n8mdZMlAprNYTZBV+CccvPE02mvxepHnCwmE4JIGWLZXL+UD PRcL37b9zkRNFFDNJPQtP31IDYXK6jQ= X-Google-Smtp-Source: ABhQp+T8SXUufpZ6l02VubnsQeDY1yD0EKgRuABKkade/YVhsh3JFUhBdMmc/cIG4skC0VuWgrUWhQ== X-Received: by 10.223.176.50 with SMTP id f47mr7664129wra.185.1508340517160; Wed, 18 Oct 2017 08:28:37 -0700 (PDT) Received: from localhost ([213.251.34.151]) by smtp.gmail.com with ESMTPSA id y15sm12205691wrc.96.2017.10.18.08.28.36 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 18 Oct 2017 08:28:36 -0700 (PDT) Message-ID: <1508340515.25747.12.camel@debian.org> From: Luca Boccassi To: Bruce Richardson Cc: dev@dpdk.org, thomas@monjalon.net, olivier.matz@6wind.com, sergio.gonzalez.monroy@intel.com Date: Wed, 18 Oct 2017 16:28:35 +0100 In-Reply-To: <20171018142024.GA14652@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> <20171018122453.GA5596@bricha3-MOBL3.ger.corp.intel.com> <20171018142024.GA14652@bricha3-MOBL3.ger.corp.intel.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Evolution 3.22.6-1+deb9u1 Mime-Version: 1.0 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 15:28:37 -0000 On Wed, 2017-10-18 at 15:20 +0100, Bruce Richardson wrote: > On Wed, Oct 18, 2017 at 01:24:54PM +0100, Bruce Richardson wrote: > > 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. > > > > > > > >=20 > > > > > > > > Signed-off-by: Bruce Richardson > > > > > > > .com> > > > > > > > > --- > > > > > > > > =C2=A0config/meson.build | 1 + > > > > > > > > =C2=A01 file changed, 1 insertion(+) > > > > > > > >=20 > > > > > > > > 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) > > > > > > > > =C2=A0add_project_arguments('-march=3D@0@'.format(machine), > > > > > > > > language: 'c') > > > > > > > > =C2=A0# some libs depend on maths lib > > > > > > > > =C2=A0add_project_link_arguments('-lm', language: 'c') > > > > > > > > +dpdk_extra_ldflags +=3D '-lm' > > > > > > > > =C2=A0 > > > > > > > > =C2=A0# add -include rte_config to cflags > > > > > > > > =C2=A0add_project_arguments('-include', 'rte_config.h', > > > > > > > > language: > > > > > > > > 'c') > > > > > > >=20 > > > > > > > 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 > > > > > >=20 > > > > > > 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 > > > > >=20 > > > > > 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. > > > > >=20 > > > > > 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. > > > > >=20 > > > > > Your input and suggestions here would be welcome. > > >=20 > > > Yes that works nicely when the libraries are rebuilt locally - > > > then it > > > can be chosen whether to build the static or dynamic ones. > > >=20 > > > 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. > > >=20 > > > 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 :-) > > >=20 > > > 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). > > >=20 > > > >=20 > > > > +Thomas, Olivier, Sergio to get more input > > > >=20 > > > > 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. > > > >=20 > > > > /Bruce > > >=20 > > > Yes that would be ideal! Right now in Debian/Ubuntu we have to > > > build > > > twice, doubling the required time unfortunately. > > >=20 > > > In theory the same objects could be packed into .ar and .so but > > > sadly > > > Meson doesn't support that yet like autotools/cmake do: > > >=20 > > > https://github.com/mesonbuild/meson/issues/484 > > >=20 > > > (please do add some feedback there as developers!) > > >=20 > > > It looks like it could be possible with some extensive hacking, > > > not > > > sure if it would be worth it. > > >=20 > >=20 > > 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. > >=20 >=20 > Seems to work fine. This change makes all the libraries (bar EAL, > which > is special-cased) appear as both .a and .so. Testpmd links against > the > dynamic versions and still works. >=20 > When I get the chance I'll see about doing the same for EAL and > drivers, > and then having the pkgconfig file reflect both possibilities. Then I > can test with some examples linking both dynamically and statically > and > check all is as expected. >=20 > /Bruce >=20 > diff --git a/lib/meson.build b/lib/meson.build > index f04cb2791..29c88548b 100644 > --- a/lib/meson.build > +++ b/lib/meson.build > @@ -76,6 +76,20 @@ foreach l:libraries > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0dep= _objs +=3D [get_variable('dep_rte_' + d)] > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0endforeach >=20 > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0libname =3D 'rte_' + name > + > +# first build static library > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0static_lib =3D static_library(libname, sources, > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0objects: = objs, > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0c_args: c= flags, > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0dependenc= ies: dep_objs, > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0include_d= irectories: > include_directories(dir_name), > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0install: = true) > + > +# now use those objects to build dynamic library > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0sources =3D [] > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0objs +=3D static_lib.extract_all_objects() > + > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0if get_option('per_library_versions') > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0lib= _version =3D '@0@.1'.format(version) > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0so_= version =3D '@0@'.format(version) > @@ -87,8 +101,7 @@ foreach l:libraries >=20 > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0version_map =3D '@0@/@1@/rte_@2@_version.map'.forma= t( > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0meson.current_source_dir(), di= r_name, > name) > -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0libname =3D 'rte_' + name > -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0lib =3D library(libname, > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0lib =3D shared_library(libname, > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0sources, > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0objects: objs, > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0c_args: cflags, Nice! Much easier than I thought reading that thread :-) I'll try to give it a test run in the next few days. Thanks! --=20 Kind regards, Luca Boccassi