[dpdk-dev] [PATCH] mk: fix the combined library problems by replacing it with a linker script
nhorman at tuxdriver.com
Tue Dec 1 14:30:43 CET 2015
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
> 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).
More information about the dev