From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id EAC061B161 for ; Tue, 19 Dec 2017 11:07:40 +0100 (CET) X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from orsmga003.jf.intel.com ([10.7.209.27]) by fmsmga102.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Dec 2017 02:07:39 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.45,426,1508828400"; d="scan'208";a="13541828" Received: from bricha3-mobl3.ger.corp.intel.com ([10.237.221.106]) by orsmga003.jf.intel.com with SMTP; 19 Dec 2017 02:07:37 -0800 Received: by (sSMTP sendmail emulation); Tue, 19 Dec 2017 10:07:36 +0000 Date: Tue, 19 Dec 2017 10:07:36 +0000 From: Bruce Richardson To: Aaron Conole Cc: Luca Boccassi , dev@dpdk.org Message-ID: <20171219100735.GC7384@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: 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: Tue, 19 Dec 2017 10:07:41 -0000 On Mon, Dec 18, 2017 at 01:05:14PM -0500, Aaron Conole wrote: > 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. > >> > > >> > 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. > > 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=ldflags.static libdpdk) $(shell pkg- > > 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. > Ok, thanks for the input. Seems like we have a consensus on the approach (which has already been merged).