Re: [dpdk-dev] [PATCH v2 1/4] mk: Remove combined library and related options

[Neil Horman <nhorman@tuxdriver.com>]

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