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

[Neil Horman <nhorman@tuxdriver.com>]

On Fri, Mar 13, 2015 at 03:28:00PM +0000, Gonzalez Monroy, Sergio wrote:
> 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.
> 
Correct, the above is the only way to create a single library that is properly
versioned, short of _only_ building a single library and exporting the version
map for that (which is non-sensical, as it defeats the purpose of DSO's).

> 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
> >>>
> 
>