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. 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) Unfortunately, again, --variable cannot be used together with --libs in the same call. -- Kind regards, Luca Boccassi
