Re: [dpdk-dev] [PATCH] mk: fix the combined library problems by replacing it with a linker script

[Neil Horman <nhorman@tuxdriver.com>]

On Tue, Dec 01, 2015 at 12:36:15PM +0000, Robie Basak wrote:
> On Tue, Dec 01, 2015 at 02:21:02PM +0200, Panu Matilainen wrote:
> > Adding a soname and a semi-arbitrary version does not fix the fundamental
> > problems:
> > 
> > Since the library lumps together everything in DPDK, you'd have to bump its
> > version whenever any of the individual libraries bumps its version to have
> > the version mean anything. DPDK 2.0 and 2.1 are supposedly binary compatible
> > but 2.2 certainly is not, and beyond that who knows.
> > 
> > That in turn forces all apps to be rebuild whenever one of the libraries
> > changes version, whether those apps use that particular library or not.
> 
> If we bundle all the libraries together into one package, then in
> distributions we have to rebuild anyway when any of the libraries
> changes version since a dependent package can't just depend on any later
> version, because we don't know in advance what ABI breaks might occur.
> It's also trivial to do rebuilds in a distribution. I'd prefer to see
> ABI versioning done right to avoid the pain that might occur there.
> Rebuilding dependent packages is on the other hand straightforward.
> 
> > The combined library doesn't have symbol versioning, so besides the better
> > version compatibility tracking it loses other benefits like limited symbol
> > visibility.
> 
> The combined library *should* have symbol versioning, which I've brought
> up before. This isn't a reason to not have a combined library; it is a
> reason to fix the combined library.
> 
Agreed, but using a linker script as the combined library gets you the proper
symbol versioning.

> Why is limited symbol visibility a benefit in this case?
> 
Because it prevents an application from inadvertently using symbols that would
otherwise appear in another library (i.e. if not using the combined library, you
know you've used a symbol in another library because you are then forced to add
that library to the build.

> > Not to mention the extra complexity in makefiles to support it, the
> > increasing amount of duct-tape required to hold it together. And still eg
> > the MLX pmds declare the configuration not supported at all.
> 
> I'd argue that this is because the build system is unnecessarily complex
> currently. A library consumer should just be able to #include
> <dpdk/foo.h> and link with -ldpdk. It should not have a build system or
> custom flags imposed on it by one of the libraries it uses.
> 
I don't disagree here, but again, modeling libdpdk.so as  a linker script gets
you to that point (or 99% of the way there at least).

Neil

> Robie
>