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
