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