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 54F47569D for ; Thu, 26 Mar 2015 11:30:28 +0100 (CET) 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 1Yb53N-0004gr-4T; Thu, 26 Mar 2015 06:30:23 -0400 Date: Thu, 26 Mar 2015 06:30:19 -0400 From: Neil Horman To: "Gonzalez Monroy, Sergio" Message-ID: <20150326103019.GA32299@hmsreliant.think-freely.org> 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> <5513C8CD.80408@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5513C8CD.80408@intel.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 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 10:30:28 -0000 On Thu, Mar 26, 2015 at 08:52:29AM +0000, Gonzalez Monroy, Sergio wrote: > 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 > I think the former makes the most sense, personally. Provide a script or automatically build the combined lib script during the build. Neil