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

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

On 13/03/2015 15:18, Neil Horman wrote:
> On Fri, Mar 13, 2015 at 04:12:35PM +0200, Stefan Puiu wrote:
>> Hi,
>>
>> 2 cents from a DPDK library user - I make 2 changes to the default
>> linux+gcc configuration: combine libraries and build shared libraries
>> (since I want 2 instances of the app, it didn't make sense to me to
>> link statically). I tried working with the individual libs, but adding
>> all of them with --start-group/-end-group just seemed so much more
>> painful than simply linking against one lib. I know there are some
>> Makefile variables to help with this, but I use scons for building my
>> app, so that doesn't help much.
>>
>> Of course, if that can be achieved easily after building all the
>> libraries, that's fine. But I think combining the libs makes a lot of
>> sense in many cases.
>>
> So do it, create a linker script that internally contains one line:
> INPUT(-lrte_eal -lrte_alarm -lrte_mempool ... etc)
>
> Name the file libdpdk.so
>
> then when you build your app, just link -ldpdk
>
> Done.
>
> Neil

Plus I believe that as it currently stands, building combined shared 
libraries will be broken
the moment we have different versions of any API because the linking for 
the combined lib
does not use a version map.

Sergio
>> Thanks,
>> Stefan.
>>
>> On Fri, Mar 13, 2015 at 3:17 PM, Neil Horman <nhorman@tuxdriver.com> wrote:
>>> On Fri, Mar 13, 2015 at 11:48:59AM +0000, Gonzalez Monroy, Sergio wrote:
>>>> On 13/03/2015 11:34, Kavanagh, Mark B wrote:
>>>>>> On 13/03/2015 10:49, Kavanagh, Mark B wrote:
>>>>>>>> ---
>>>>>>>> config/common_bsdapp                        |   6 --
>>>>>>>> config/common_linuxapp                      |   6 --
>>>>>>>> config/defconfig_ppc_64-power8-linuxapp-gcc |   2 -
>>>>>>>> lib/Makefile                                |   1 -
>>>>>>>> mk/rte.app.mk                               |  12 ----
>>>>>>>> mk/rte.lib.mk                               |  35 ----------
>>>>>>>> mk/rte.sdkbuild.mk                          |   3 -
>>>>>>>> mk/rte.sharelib.mk                          | 101 ----------------------------
>>>>>>>> mk/rte.vars.mk                              |   9 ---
>>>>>>>> 9 files changed, 175 deletions(-)
>>>>>>>> delete mode 100644 mk/rte.sharelib.mk
>>>>>>>>
>>>>>>>> diff --git a/config/common_bsdapp b/config/common_bsdapp
>>>>>>>> index 8ff4dc2..7ee5ecf 100644
>>>>>>>> --- a/config/common_bsdapp
>>>>>>>> +++ b/config/common_bsdapp
>>>>>>>> @@ -79,12 +79,6 @@ CONFIG_RTE_FORCE_INTRINSICS=n
>>>>>>>> CONFIG_RTE_BUILD_SHARED_LIB=n
>>>>>>>>
>>>>>>>> #
>>>>>>>> -# Combine to one single library
>>>>>>>> -#
>>>>>>>> -CONFIG_RTE_BUILD_COMBINE_LIBS=n
>>>>>>>> -CONFIG_RTE_LIBNAME=intel_dpdk
>>>>>>> Hi Sergio,
>>>>>>>
>>>>>>> Removing these options breaks compatibility with OVS. While it may be feasible to link
>>>>>> to individual static libraries, in our experience, a single combined library provides a
>>>>>> much more convenient way of linking.
>>>>>>> Thanks,
>>>>>>> Mark
>>>>>>>
>>>>>>>> -
>>>>> (snip)
>>>>>
>>>>>
>>>>>>>> -endif
>>>>>>>> -
>>>>>>>> -RTE_LIBNAME := $(CONFIG_RTE_LIBNAME:"%"=%)
>>>>>>>> -ifeq ($(RTE_LIBNAME),)
>>>>>>>> -RTE_LIBNAME := intel_dpdk
>>>>>>>> endif
>>>>>>>>
>>>>>>>> # RTE_TARGET is deducted from config when we are building the SDK.
>>>>>>>> --
>>>>>>>> 1.9.3
>>>>>> Hi Mark,
>>>>>>
>>>>>> How does this patch break compatibility with OVS?
>>>>>>
>>>>>> Thanks,
>>>>>> Sergio
>>>>> Hey Sergio,
>>>>>
>>>>> We use the CONFIG_RTE_BUILD_COMBINE_LIBS and CONFIG_RTE_LINBNAME flags to build a single static DPDK library, named 'libintel_dpdk.a', which OVS links against. Removing the combined library option breaks compatibility with any application that links against the combined DPDK library.
>>>>>
>>>>> Is there a strong technical motivation for removing these options?
>>>>>
>>>>> Thanks,
>>>>> Mark
>>>>  From a shared library point of view, it just does not make sense to have
>>>> applications linked against a 'combined' library that may have different
>>>> features built in it.
>>>>
>>>> Removing these options, aside from the obvious 'less build config option',
>>>> it simplifies maintenance of makefiles as we currently have a separated
>>>> makefile with specific rules just for combined library.
>>>>
>>>> It is pretty straight forward to build a single combined archive out of
>>>> multiple archives, would it be acceptable to have a script to do this?
>>>>
>>>> Thanks,
>>>> Sergio
>>>>
>>> +1
>>>
>>> For the static case, its easy to do a post build combination of archives.  For
>>> the shared library case, its equally easy to simply create a linker scripts call
>>> <CONFIG_RTE_LIBNAME>.so that pulls in all the individual libraries.
>>>
>>> Neil
>>>