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. Thanks, Stefan. On Fri, Mar 13, 2015 at 3:17 PM, Neil Horman <nhorman at 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 >
