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 906E51396 for ; Thu, 26 Mar 2015 09:52:31 +0100 (CET) Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga102.fm.intel.com with ESMTP; 26 Mar 2015 01:52:30 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.11,470,1422950400"; d="scan'208";a="472878485" Received: from smonroyx-mobl.ger.corp.intel.com (HELO [10.237.220.42]) ([10.237.220.42]) by FMSMGA003.fm.intel.com with ESMTP; 26 Mar 2015 01:52:29 -0700 Message-ID: <5513C8CD.80408@intel.com> Date: Thu, 26 Mar 2015 08:52:29 +0000 From: "Gonzalez Monroy, Sergio" User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Thomas Monjalon References: <1422544811-26385-1-git-send-email-sergio.gonzalez.monroy@intel.com> <1426177681-16931-2-git-send-email-sergio.gonzalez.monroy@intel.com> <55096B86.7040303@intel.com> <40763037.Qv1hPgBHv0@xps13> In-Reply-To: <40763037.Qv1hPgBHv0@xps13> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: dev@dpdk.org Subject: Re: [dpdk-dev] [PATCH v2 1/4] 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, 26 Mar 2015 08:52:32 -0000 On 18/03/2015 12:59, Thomas Monjalon wrote: > Hi Sergio, > > Thank you for explaining the situation. > > 2015-03-18 12:11, Gonzalez Monroy, Sergio: >> Given that the patch to remove combined libraries is not welcome, I'll >> try to explain the current situation so we can agree on the way forward. >> >> Currently we have build config option for shared libraries and combined >> libraries. Thus, this results in four possible combinations when >> building dpdk: >> - not combined static >> - not combined shared >> - combined static >> - combined shared >> >> The makefile rules/targets for combined are different than for not >> combined. Thus, we currently have two different files for >> archive/linking (rte.lib.mk and rte.sharelib.mk). >> >> Since having versioning, combined shared libraries build will be broken >> the moment we add a versioned API, as we do not have a global version >> map that we use when linking such library. >> Also in my opinion, we would want to prevent users linking against a >> combined libdpdk.so that may have different features built-in, with the >> corresponding debugging difficulties when users >> report different problems/errors. I think this would defeat many of the >> advantages of using shared libraries. >> >> By removing the combined library build option, we would simplify the >> build system with only two possible choices: >> - static >> - shared > +1 > I believe that simplification is the way go. > >> This would allow us to remove one file (rte.sharelib.mk) and have a >> single file with archive/linking rules. >> >> For the convenience of linking against a single library instead of the >> multiple dpdk libraries, there are a few ways to go around it: >> - for combined static lib, we can either have a script to re-archive >> all libraries into a single/combined library (ie. extract all archives >> into one directory, the re-archive all objects into a combined library), >> or use a linker script (ie. GROUP ( -lrte_eal -lrte_malloc ... ) ). >> - for combined shared lib, we can use a linker script (ie. INPUT ( >> -lrte_eal -lrte_malloc ... AS_NEEDED -lrte_hash ...) ) or we could use a >> global version map (either somehow merging all independent version maps >> or maintaining a global version map). >> >> My preference would be to remove the combined libs as a build config >> option, then either add scripts to create those linker scripts or >> document it so users know how to create their own linker scripts. >> This would simplify the build process and still be able to provide the >> convenience of the combined library by using a linker script. >> >> Comments? > You're right about the word convenience. > There are many ways to provide such convenience. > The first one is to simply use the DPDK makefiles which abstract linking problems. > If using DPDK framework is not an option, we can add new conveniences like > scripts or pkgconfig support. > So for v3, do we provide such script/pkgconfig or just documentation on how to create it? Sergio