From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Monjalon Subject: Re: [PATCH 0/8] Improve build process Date: Thu, 29 Jan 2015 18:02:28 +0100 Message-ID: <6409263.pK80EifcFX@xps13> References: <1422544811-26385-1-git-send-email-sergio.gonzalez.monroy@intel.com> <20150129163859.GE1999@hmsreliant.think-freely.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit Cc: dev-VfR2kkLFssw@public.gmane.org To: Neil Horman Return-path: In-Reply-To: <20150129163859.GE1999-B26myB8xz7F8NnZeBjwnZQMhkBWG/bsMQH7oEaQurus@public.gmane.org> 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" 2015-01-29 11:38, Neil Horman: > On Thu, Jan 29, 2015 at 03:20:03PM +0000, Sergio Gonzalez Monroy wrote: > > This patch series improves the DPDK build system mostly for shared > > libraries (and a few nits for static libraries) with the following goals: > > - Create a library containing core DPDK libraries (librte_eal, > > librte_malloc, librte_mempool, librte_mbuf and librte_ring). > > The idea of core libraries is to group those libraries that are > > always required (and have interdependencies) for any DPDK application. > > - Remove config option to build a combined library. > > - For shared libraries, explicitly link against dependant > > libraries (adding entries to DT_NEEDED). > > - Update app linking flags for static/shared DPDK libs. > > > > Sergio Gonzalez Monroy (8): > > mk: remove combined library and related options > > core: create new librte_core > > mk: new corelib makefile > > lib: update DEPDIRS variable > > lib: set LDLIBS for each library > > mk: use LDLIBS when linking shared libraries > > mk: update LDLIBS for app building > > mk: add -lpthread to linuxapp EXECENV_LDLIBS > > > Something occured to me thinking about this patch set. I noticed recently that > different rules are used to build the shared combined lib from the individual > shared objects. The implication here is that linker options specified in > individual make files (like the LIBABIVER and EXPORT_MAP options in my ABI > versioning script) get ignored, which is bad. Any other file specific linker > options (like _LDFLAGS specified in individual library makefiles are > getting dropped for the combined lib. > > It seems like it would be better if the combined libs were manufactured as > linker scripts themselves (textfiles that used linker directives to include > individual libraries under the covers (see /lib64/libc.so for an example). > > The disadvantage of such an approach are fairly minimal. With such a combined > library, you still need to install individual libraries, but for applications > that wish to link and run against a single dpdk library will still work just as > they currently do, you can link to just a single library. > > The advantage is clear however. By following a linker script aproach, objects > build as separate libraries are built exactly the same way, using the same rules > with the same options. It reduces the dpdk build environment size and > complexity, and reduces the opportunity for bugs to creep in from forgetting to > add build options to multiple locations. It also provides a more granular > approach for grouping files. Creating a dpdk core library becomes a matter of > creating a one line linker script named libdpdk_core.so, rather than re-arraning > sections of the build system. > > Thoughts? Neil, it seems to be a good idea. I like the idea of making things simpler ;) -- Thomas