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 >
