Re: [dpdk-dev] [PATCH 0/6] next-build: create both static and shared libs

[Aaron Conole <aconole@redhat.com>]

Luca Boccassi <bluca@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.