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