From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by dpdk.org (Postfix) with ESMTP id C3A559FE for ; Wed, 13 Dec 2017 14:28:39 +0100 (CET) X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga101.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 13 Dec 2017 05:28:38 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.45,397,1508828400"; d="scan'208";a="13118177" Received: from bricha3-mobl3.ger.corp.intel.com ([10.237.221.106]) by fmsmga001.fm.intel.com with SMTP; 13 Dec 2017 05:28:36 -0800 Received: by (sSMTP sendmail emulation); Wed, 13 Dec 2017 13:28:36 +0000 Date: Wed, 13 Dec 2017 13:28:35 +0000 From: Bruce Richardson To: Luca Boccassi Cc: dev@dpdk.org, aconole@redhat.com Message-ID: <20171213132835.GB10724@bricha3-MOBL3.ger.corp.intel.com> References: <20171212165940.272969-1-bruce.richardson@intel.com> <20171212171401.GA14780@bricha3-MOBL3.ger.corp.intel.com> <1513167052.15861.26.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: <1513167052.15861.26.camel@debian.org> Organization: Intel Research and Development Ireland Ltd. User-Agent: Mutt/1.9.1 (2017-09-22) 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: Wed, 13 Dec 2017 13:28:40 -0000 On Wed, Dec 13, 2017 at 12:10:52PM +0000, Luca Boccassi wrote: > 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. > > > > > > 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.  It also procludes adding in the -Wl,-Bstatic flag > > > into the output for the standard libraries to link them statically. > > > > > > 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. > > > > > > 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. > > > > > > > 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! > > > > /Bruce > > I don't link #1 too much - too "special". I think an additional flag is > more friendly. > Yes, it is not very neat indeed. The main advantage of it would include the fact that we could do away with all the -Wl,-Bstatic/-Bdynamic flags completely, and have the libs line just have the direct paths to the .a files. > A good solution would be a Cflags.private feature, sadly that is not > supported by pkgconfig despite many requests for it. > Not sure that would help. It's the ldflags that need to be special-cased, as far as I can see. > 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=ldflags.static libdpdk) $(shell pkg- > config --static --libs libdpdk) > > Unfortunately, again, --variable cannot be used together with --libs in > the same call. Yes, that could work, but having the user specific a special variable from pkgconfig is just as much work as just telling the user to add -Wl,-Bstatic to their existing pkg-config lines. In any case, none of this is cast in stone. Even after this is merged, we can support #1 alongside this if that turns out to be easier for users. /Bruce