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

["Gonzalez Monroy, Sergio" <sergio.gonzalez.monroy@intel.com>]

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