[dpdk-dev] [PATCH 0/4] Fix build issues with CONFIG_RTE_BUILD_COMBINE_LIBS=y

[Sergio Gonzalez Monroy]

On Thu, Oct 02, 2014 at 04:24:51PM -0400, Neil Horman wrote:
> On Thu, Oct 02, 2014 at 01:04:20PM -0700, Matthew Hall wrote:
> > On Thu, Oct 02, 2014 at 01:26:34PM -0400, Neil Horman wrote:
> > > Just out of curiosity, whats the impetus behind a single shared library here?
> > > Is it just to ease application linking operations?  If so, it almost seems to me
> > > that we should abandon the individual linking method and just use this as the
> > > default output (and do simmilarly for the static linking build)
> > > 
> > > Neil
> > 
> > Not clear if you wrote "single shared library" on purpose instead of "single 
> > static library". But for me the objective of COMBINE_LIBS usage would be 
> > getting a "single static library" for my app, which just works, and eliminates 
> > need of start-group, end-group, weird library ordering issues, etc. I'm not 
> > interested personally in a "shared library" because it'd run slower.
> > 
> Actually I do need to revise my question, thank you.  you're right, doing a
> single archive for static builds makes the most sense, because you wind up with
> a static binary anyway, and as such, theres really no need for multiple dpdk
> archives.  We should just create a single dpdk.a file and be done with it.
> 
> The shared libraries are a different story.  While at first it made sense to me
> to merge them all, it actually doesn't because PMD's might be built
> independently and shipped separate from the core library.  

Sorry Neil, could you elaborate a bit on why it would not make sense to have a 
single/combined shared library?

Sergio

> 
> > Personally my preference would be to do both the single libs and multiple libs 
> > in static format by default. Disk space is cheap, let's maximize user freedom 
> > and flexibility. But shared lib, since it performs less well, should be 
> > discouraged by default, although allowed if needed... some people prefer it 
> > because it's easier to patch security vulns if you can replace a buggy library 
> > for all the code on a system.
> > 
> This seems somewhat irrelevant to the patch.  The default configuration is
> already the way you want it to be, shared library performance is actually very
> close to static performance, and yes, people can choose how they want to build.
> Not sure what point your trying to make here.
> Neil
> 
> > Matthew.
> >