From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.tuxdriver.com (charlotte.tuxdriver.com [70.61.120.58]) by dpdk.org (Postfix) with ESMTP id 989425921 for ; Thu, 9 Apr 2015 22:34:20 +0200 (CEST) Received: from hmsreliant.think-freely.org ([2001:470:8:a08:7aac:c0ff:fec2:933b] helo=localhost) by smtp.tuxdriver.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1YgJ9O-0004Bz-CM; Thu, 09 Apr 2015 16:34:16 -0400 Date: Thu, 9 Apr 2015 16:34:09 -0400 From: Neil Horman To: Avi Kivity Message-ID: <20150409203409.GB29807@hmsreliant.think-freely.org> References: <1428505645-5578-1-git-send-email-sergio.gonzalez.monroy@intel.com> <1428505645-5578-2-git-send-email-sergio.gonzalez.monroy@intel.com> <20150408112619.14596b65@urahara> <55263955.1070707@intel.com> <55264127.2020604@cloudius-systems.com> <20150409111943.GA26201@hmsreliant.think-freely.org> <5526B02A.70700@cloudius-systems.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5526B02A.70700@cloudius-systems.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Score: -2.9 (--) X-Spam-Status: No Cc: dev@dpdk.org Subject: Re: [dpdk-dev] [PATCH v3 1/5] mk: remove combined library and related options X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Apr 2015 20:34:21 -0000 On Thu, Apr 09, 2015 at 08:00:26PM +0300, Avi Kivity wrote: > On 04/09/2015 02:19 PM, Neil Horman wrote: > >On Thu, Apr 09, 2015 at 12:06:47PM +0300, Avi Kivity wrote: > >> > >>On 04/09/2015 11:33 AM, Gonzalez Monroy, Sergio wrote: > >>>On 08/04/2015 19:26, Stephen Hemminger wrote: > >>>>On Wed, 8 Apr 2015 16:07:21 +0100 > >>>>Sergio Gonzalez Monroy wrote: > >>>> > >>>>>Currently, the target/rules to build combined libraries is different > >>>>>than the one to build individual libraries. > >>>>> > >>>>>By removing the combined library option as a build configuration option > >>>>>we simplify the build pocess by having a single point for > >>>>>linking/archiving > >>>>>libraries in DPDK. > >>>>> > >>>>>This patch removes CONFIG_RTE_BUILD_COMBINE_LIB build config option and > >>>>>removes the makefiles associated with building a combined library. > >>>>> > >>>>>The CONFIG_RTE_LIBNAME config option is kept as it will be use to > >>>>>always generate a linker script that acts as a single combined library. > >>>>> > >>>>>Signed-off-by: Sergio Gonzalez Monroy > >>>>> > >>>>No. We use combined library and it greatly simplfies the application > >>>>linking process. > >>>> > >>>After all the opposition this patch had in v2, I did explain the current > >>>issues > >>>(see http://dpdk.org/ml/archives/dev/2015-March/015366.html ) and this was > >>>the agreed solution. > >>> > >>>As I mention in the cover letter (also see patch 2/5), building DPDK > >>>(after applying this patch series) will always generate a very simple > >>>linker script that behaves as a combined library. > >>>I encourage you to apply this patch series and try to build your app > >>>(which links against combined lib). > >>>Your app should build without problem unless I messed up somewhere and it > >>>needs fixing. > >>Is it possible to generate a pkgconfig file (dpdk.pc) that contains all of > >>the setting needed to compile and link with dpdk? That will greatly > >>simplify usage. > >> > >>A linker script is just too esoteric. > >> > >Why esoteric? We're not talking about a linker script in the sense of a binary > >layout file, we're talking about a prewritten/generated libdpdk_core.so that > >contains linker directives to include the appropriate libraries. You link it > >just like you do any other library, but it lets you ignore how they are broken > >up. > > You mean DT_NEEDED? That's great, but it shouldn't be called a linker > script. > no, I don't mean DT_NEEDED, I mean a linker script, because thats what what sergio wrote is. > >We could certainly do a pkg-config file, but I don't think thats any more > >adventageous than this solution. > > It solves more problems -- cflags etc. Of course having the right DT_NEEDED > is a good thing regardless. > Thats a good point, pkgconfig doesn't provide that additionally. Perhaps having both is the best solution. As for the DT_NEEDED issues, the earlier threads ennumerated all the problems that were being found with the way the libraries were organized (circular dependencies). Neil