From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Gonzalez Monroy, Sergio" Subject: Re: [PATCH v2 1/4] mk: Remove combined library and related options Date: Thu, 26 Mar 2015 08:52:29 +0000 Message-ID: <5513C8CD.80408@intel.com> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Cc: dev-VfR2kkLFssw@public.gmane.org To: Thomas Monjalon Return-path: In-Reply-To: <40763037.Qv1hPgBHv0@xps13> List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces-VfR2kkLFssw@public.gmane.org Sender: "dev" 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