From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by dpdk.org (Postfix) with ESMTP id 9416E271 for ; Mon, 18 Dec 2017 19:05:16 +0100 (CET) Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id E9205C001600; Mon, 18 Dec 2017 18:05:15 +0000 (UTC) Received: from dhcp-25.97.bos.redhat.com (unknown [10.18.25.61]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 786A080946; Mon, 18 Dec 2017 18:05:15 +0000 (UTC) From: Aaron Conole To: Luca Boccassi Cc: Bruce Richardson , dev@dpdk.org References: <20171212165940.272969-1-bruce.richardson@intel.com> <20171212171401.GA14780@bricha3-MOBL3.ger.corp.intel.com> <1513167052.15861.26.camel@debian.org> Date: Mon, 18 Dec 2017 13:05:14 -0500 In-Reply-To: <1513167052.15861.26.camel@debian.org> (Luca Boccassi's message of "Wed, 13 Dec 2017 12:10:52 +0000") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.90 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.31]); Mon, 18 Dec 2017 18:05:16 +0000 (UTC) Subject: Re: [dpdk-dev] [PATCH 0/6] next-build: create both static and shared libs 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: Mon, 18 Dec 2017 18:05:17 -0000 Luca Boccassi writes: > On Tue, 2017-12-12 at 17:14 +0000, Bruce Richardson wrote: >> On Tue, Dec 12, 2017 at 04:59:34PM +0000, Bruce Richardson wrote: >> > This patchset changes the meson+ninja build system to always create >> > both >> > static and shared libraries when doing a build. The applications >> > compiled >> > as part of a build use either the shared or static libraries >> > depending on >> > what the default_library build setting is. >> >=20 >> > NOTE: >> > The main difficulty with this change is adjusting the pkgconfig >> > file so >> > that external apps, like the examples, can be built using either >> > the static >> > or shared libraries. One of the key issues was the fact that >> > running >> > "pkg-config --static --libs libdpdk" outputs first the normal libs, >> > and >> > then the extra static ones. This is a problem because the driver >> > libs are >> > for static only builds, but need to come before, not after the >> > standard >> > DDPK libraries.=C2=A0=C2=A0It also procludes adding in the -Wl,-Bstati= c flag >> > into the output for the standard libraries to link them statically. >> >=20 >> > There were two options considered for mananging the pkg-config >> > settings. >> > 1. Creating a separate .pc file for static builds with exactly the >> > flags >> > needed. >> > 2. Modifying the single .pc file so that it was "good enough" to >> > enable >> > static builds without too much work. >> >=20 >> > For this version of this set, I took option #2. To link using >> > dynamic libs, >> > all is as normal, to use static libs, the user needs to prepend >> > "-Wl,-Bstatic" before the "pkgconfig --static" library output. This >> > can be >> > seen in the changes to the example application makefiles, which now >> > support >> > building the examples using shared or static DPDK libs. >> >=20 >>=20 >> Just to emphasise that I'm looking for input into whether I took the >> right choice here. Option #1 has some advantages in that we can tune >> the >> output specifically for the static build case, but I wasn't sure >> whether >> it would be the done thing to have two different .pc files for a >> single >> package. Feedback from packagers welcome! >>=20 >> /Bruce > > I don't link #1 too much - too "special". I think an additional flag is > more friendly. I agree with this. > A good solution would be a Cflags.private feature, sadly that is not > supported by pkgconfig despite many requests for it. > > A possible way to sugar-coat it could be to add a custom variable, and > then instruct the users to do something like: > > $(shell pkg-config --variable=3Dldflags.static libdpdk) $(shell=C2=A0pkg- > config --static --libs libdpdk) I don't think this is needed. Most linkers (and libtool based linkers as well) have no 'distinction' between static / dynamic - just the static option gets passed. In this case, I think it's fine to require the application build system to expose such a distinct option to the user doing the builds. There's generally no good reasons to want static builds (well... okay that's a bit strong, but hopefully I don't get my head chewed off) anyway, so making them slightly more work is okay by me. > Unfortunately, again, --variable cannot be used together with --libs in > the same call.