DPDK patches and discussions
 help / color / mirror / Atom feed
From: Bruce Richardson <bruce.richardson@intel.com>
To: Luca Boccassi <bluca@debian.org>
Cc: dev@dpdk.org, aconole@redhat.com
Subject: Re: [dpdk-dev] [PATCH 0/6] next-build: create both static and shared libs
Date: Wed, 13 Dec 2017 13:28:35 +0000	[thread overview]
Message-ID: <20171213132835.GB10724@bricha3-MOBL3.ger.corp.intel.com> (raw)
In-Reply-To: <1513167052.15861.26.camel@debian.org>

On Wed, Dec 13, 2017 at 12:10:52PM +0000, Luca Boccassi wrote:
> 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.
> 

Yes, it is not very neat indeed. The main advantage of it would include
the fact that we could do away with all the -Wl,-Bstatic/-Bdynamic flags
completely, and have the libs line just have the direct paths to the .a
files.

> A good solution would be a Cflags.private feature, sadly that is not
> supported by pkgconfig despite many requests for it.
> 
Not sure that would help. It's the ldflags that need to be
special-cased, as far as I can see.

> 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.

Yes, that could work, but having the user specific a special variable
from pkgconfig is just as much work as just telling the user to add
-Wl,-Bstatic to their existing pkg-config lines.

In any case, none of this is cast in stone. Even after this is merged,
we can support #1 alongside this if that turns out to be easier for
users.

/Bruce

  reply	other threads:[~2017-12-13 13:28 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-12 16:59 Bruce Richardson
2017-12-12 16:59 ` [dpdk-dev] [PATCH 1/6] build: remove library special cases Bruce Richardson
2017-12-12 16:59 ` [dpdk-dev] [PATCH 2/6] eal: fix list of source files to meson build Bruce Richardson
2017-12-12 16:59 ` [dpdk-dev] [PATCH 3/6] build: build all libs and drivers as both static and shared Bruce Richardson
2017-12-12 16:59 ` [dpdk-dev] [PATCH 4/6] build: change default library type to static Bruce Richardson
2017-12-12 16:59 ` [dpdk-dev] [PATCH 5/6] build: symlink drivers to library directory Bruce Richardson
2017-12-12 16:59 ` [dpdk-dev] [PATCH 6/6] examples: enable linking examples both static and shared Bruce Richardson
2017-12-12 17:14 ` [dpdk-dev] [PATCH 0/6] next-build: create both static and shared libs Bruce Richardson
2017-12-13 12:10   ` Luca Boccassi
2017-12-13 13:28     ` Bruce Richardson [this message]
2017-12-18 18:05     ` Aaron Conole
2017-12-19 10:07       ` Bruce Richardson
2017-12-13 12:11 ` Luca Boccassi
2017-12-15 12:02   ` Bruce Richardson

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20171213132835.GB10724@bricha3-MOBL3.ger.corp.intel.com \
    --to=bruce.richardson@intel.com \
    --cc=aconole@redhat.com \
    --cc=bluca@debian.org \
    --cc=dev@dpdk.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).