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