[dpdk-dev] [PATCH 0/6] next-build: create both static and shared libs
bruce.richardson at intel.com
Tue Dec 19 11:07:36 CET 2017
On Mon, Dec 18, 2017 at 01:05:14PM -0500, Aaron Conole wrote:
> Luca Boccassi <bluca at debian.org> writes:
> > On Tue, 2017-12-12 at 17:14 +0000, Bruce Richardson wrote:
> >> On Tue, Dec 12, 2017 at 04:59:34PM +0000, Bruce Richardson wrote:
> >> > This patchset changes the meson+ninja build system to always create
> >> > both
> >> > static and shared libraries when doing a build. The applications
> >> > compiled
> >> > as part of a build use either the shared or static libraries
> >> > depending on
> >> > what the default_library build setting is.
> >> >
> >> > NOTE:
> >> > The main difficulty with this change is adjusting the pkgconfig
> >> > file so
> >> > that external apps, like the examples, can be built using either
> >> > the static
> >> > or shared libraries. One of the key issues was the fact that
> >> > running
> >> > "pkg-config --static --libs libdpdk" outputs first the normal libs,
> >> > and
> >> > then the extra static ones. This is a problem because the driver
> >> > libs are
> >> > for static only builds, but need to come before, not after the
> >> > standard
> >> > DDPK libraries. It also procludes adding in the -Wl,-Bstatic flag
> >> > into the output for the standard libraries to link them statically.
> >> >
> >> > There were two options considered for mananging the pkg-config
> >> > settings.
> >> > 1. Creating a separate .pc file for static builds with exactly the
> >> > flags
> >> > needed.
> >> > 2. Modifying the single .pc file so that it was "good enough" to
> >> > enable
> >> > static builds without too much work.
> >> >
> >> > For this version of this set, I took option #2. To link using
> >> > dynamic libs,
> >> > all is as normal, to use static libs, the user needs to prepend
> >> > "-Wl,-Bstatic" before the "pkgconfig --static" library output. This
> >> > can be
> >> > seen in the changes to the example application makefiles, which now
> >> > support
> >> > building the examples using shared or static DPDK libs.
> >> >
> >> Just to emphasise that I'm looking for input into whether I took the
> >> right choice here. Option #1 has some advantages in that we can tune
> >> the
> >> output specifically for the static build case, but I wasn't sure
> >> whether
> >> it would be the done thing to have two different .pc files for a
> >> single
> >> package. Feedback from packagers welcome!
> >> /Bruce
> > I don't link #1 too much - too "special". I think an additional flag is
> > more friendly.
> I agree with this.
> > A good solution would be a Cflags.private feature, sadly that is not
> > supported by pkgconfig despite many requests for it.
> > A possible way to sugar-coat it could be to add a custom variable, and
> > then instruct the users to do something like:
> > $(shell pkg-config --variable=ldflags.static libdpdk) $(shell pkg-
> > config --static --libs libdpdk)
> I don't think this is needed. Most linkers (and libtool based linkers
> as well) have no 'distinction' between static / dynamic - just the
> static option gets passed.
> In this case, I think it's fine to require the application build system
> to expose such a distinct option to the user doing the builds. There's
> generally no good reasons to want static builds (well... okay that's a
> bit strong, but hopefully I don't get my head chewed off) anyway, so
> making them slightly more work is okay by me.
Ok, thanks for the input. Seems like we have a consensus on the approach
(which has already been merged).
More information about the dev