From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 837B0A0613 for ; Tue, 24 Sep 2019 14:12:03 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 4AA782C18; Tue, 24 Sep 2019 14:12:02 +0200 (CEST) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id 453662C16 for ; Tue, 24 Sep 2019 14:11:59 +0200 (CEST) X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from orsmga008.jf.intel.com ([10.7.209.65]) by orsmga102.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Sep 2019 05:11:59 -0700 X-IronPort-AV: E=Sophos;i="5.64,544,1559545200"; d="scan'208";a="182894603" Received: from bricha3-mobl.ger.corp.intel.com ([10.237.221.95]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Sep 2019 05:11:55 -0700 Date: Tue, 24 Sep 2019 13:11:52 +0100 From: Bruce Richardson To: Andrzej Ostruszka Cc: Thomas Monjalon , Ray Kinsella , dev@dpdk.org, Aaron Conole , Michael Santana , John McNamara , Marko Kovacevic , David Hunt , Vladimir Medvedkin , Robert Sanford , Erik Gabriel Carrillo , mattias.ronnblom@ericsson.com, stephen@networkplumber.org, Andrzej Ostruszka , nhorman@tuxdriver.com Message-ID: <20190924121151.GA877@bricha3-MOBL.ger.corp.intel.com> References: <20190919151624.GA1999@bricha3-MOBL.ger.corp.intel.com> <1873473.QF300kEeir@xps> <20190923120658.GA2003@bricha3-MOBL.ger.corp.intel.com> <20190923161326.GB2003@bricha3-MOBL.ger.corp.intel.com> <42bc3e03-768f-b90c-5f81-5a1cb525bb2f@semihalf.com> <20190924102534.GA2021@bricha3-MOBL.ger.corp.intel.com> <936ad1c2-ad0d-7026-9597-f45e35ad4133@semihalf.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <936ad1c2-ad0d-7026-9597-f45e35ad4133@semihalf.com> User-Agent: Mutt/1.11.4 (2019-03-13) Subject: Re: [dpdk-dev] [PATCH v2 01/10] build: add an option to enable LTO build 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: , Errors-To: dev-bounces@dpdk.org Sender: "dev" On Tue, Sep 24, 2019 at 01:52:23PM +0200, Andrzej Ostruszka wrote: > > On 9/24/19 12:25 PM, Bruce Richardson wrote: > > On Tue, Sep 24, 2019 at 08:46:25AM +0200, Andrzej Ostruszka wrote: > [...] > >> PS. IMHO this SHARED_LIB define should be removed from the rte_config.h > >> and meson.build should be updated to detect 'default_library' and add it > >> as needed. Don't know exactly how meson behaves if 'default_library' is > >> 'both' - the docs say that it reuses objects from static build, so we > >> might have to work around it for LTO & 'both'. > > > > That proposal won't work either as we build both static and shared > > libraries in all cases - the default_library value only affects whether the > > test apps are linked against the .a or .so files. > > > > The real issue seems to be that the compat.h header has different > > compilation paths for static and shared libraries, which means that any C > > file including it can't have a .o file that can be used for both a .a and a > > .so simultaneously. Having it default to the shared library path seems to > > work fine thus far, but with LTO it seems broken as you say. Adding Neil as > > the original file author of this in case he has any suggestions here. I'd > > really rather not have to go back to building .a's and .so's separately. > > I thought about this already a bit and I see two ways out. > > The one which depends on meson's 'default_library' - for > "static"/"shared" the case would be easy (along the lines I've > mentioned). The "both" would be tricky if we want to rely on meson > built-in behaviour. > Ignoring the both case, which I think is just unsupported right now - it wasn't there when we added support originally for building DPDK - using the shared/static setting still won't solve the problem since it only applied to DPDK's own apps. The reason for building both static and shared libs is to give apps the flexibility to link against either as they prefer - using the pkg-config appropriately. It's perfectly valid to have testpmd linked statically in a DPDK build so that it can be run from the build directory, yet have other apps on the system linked dynamically. > The other is that we use 'default_library' as we do today (as an > indicator which library should be used when linking apps). In that case > all is good apart from building static libs out of object files. That > would require additional step. That is each object, for which source > uses BIND_DEFAULT_SYMBOL/MAP_STATIC_SYMBOL, would need to be processed > with "objcopy --add-symbol" adding correct alias before being used to > create static lib. > Interesting. It seems a bit awkward a solution, but may be doable. > Just my 2 cents. > > Regards > Andrzej