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 52A71591A for ; Mon, 13 Apr 2015 11:52:40 +0200 (CEST) Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga102.fm.intel.com with ESMTP; 13 Apr 2015 02:52:39 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.11,569,1422950400"; d="scan'208";a="480173807" Received: from smonroyx-mobl.ger.corp.intel.com (HELO [10.237.220.49]) ([10.237.220.49]) by FMSMGA003.fm.intel.com with ESMTP; 13 Apr 2015 02:52:38 -0700 Message-ID: <552B91E5.9070803@intel.com> Date: Mon, 13 Apr 2015 10:52:37 +0100 From: "Gonzalez Monroy, Sergio" User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: Neil Horman 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> <20150409203409.GB29807@hmsreliant.think-freely.org> In-Reply-To: <20150409203409.GB29807@hmsreliant.think-freely.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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: Mon, 13 Apr 2015 09:52:41 -0000 On 09/04/2015 21:34, Neil Horman wrote: > 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 I am not entirely sure of the conclusion of this thread. Are we happy with the current linker script solution as a replacement of the combined lib? Do we want to provide pkg-config file in addition or instead of linker script? I think I will split the series as there seems to be no objections to the patches related to DT_NEEDED entries. I'll post a series for DT_NEEDED entries and another series for dealing with the combined lib (once we get to an agreement). Does it sound reasonable? Sergio