DPDK patches and discussions
 help / color / mirror / Atom feed
From: Thomas Monjalon <thomas@monjalon.net>
To: Gabriel Ganne <gabriel.ganne@6wind.com>
Cc: Bruce Richardson <bruce.richardson@intel.com>,
	Thierry Herbelot <thierry.herbelot@6wind.com>,
	dev@dpdk.org, Olivier Matz <olivier.matz@6wind.com>,
	david.marchand@redhat.com
Subject: Re: [dpdk-dev] [PATCH v3] meson: remove unnecessary explicit link to libpcap
Date: Fri, 09 Apr 2021 11:24:18 +0200	[thread overview]
Message-ID: <2147114.uPvM74KM6J@thomas> (raw)
In-Reply-To: <CAGFdkHT9RAgG6pjiYbd_f=PiT2JGxmWxYehbaFPT6HR2yu6Nag@mail.gmail.com>

09/04/2021 10:31, Gabriel Ganne:
> Hi Thomas,
> 
> Thanks for the review.
> 
> The use case that made me see this is that I configured the dpdk using meson
> option "-- default_library=static" in conjunction with buildroot which is
> patching
> meson to prefer static libraries in this case.
> This causes the link line generated from the dependency() directive to
> result
> in an expanded "/path/to/libpcap.a".
> The dpdk_extra_ldflags += '-lpcap' is a direct (manual) addition to the
> link line
> that cannot be changed in the same way.

No it is only changing the generated pkg-config file.
I think you are messing between what happens in DPDK build,
and what your specific environment/application does.

> In this specific setup, the change is the following:
> Before:
>   -lpcap /path/to/libpcap.a
> After:
>   /path/to/libpcap.a

The real before/after is in the pkg-config file as I showed below.

> I admit this is quite the corner case (and probably not a great idea).
> 
> I will replace that confusing second paragraph with the comment you made
> regarding " ext_deps += pcap_dep".

You missed my other comments.
I will propose a v5 with my explanations.

PS: please avoid top-post.


> On Fri, Apr 9, 2021 at 12:39 AM Thomas Monjalon <thomas@monjalon.net> wrote:
> > Thank you, the fix looks good.
> > I would like to improve the explanation.
> >
> > If I understand the issue, the title should be
> > "build: remove redundant libpcap link"
> >
> > 26/03/2021 09:22, Gabriel Ganne:
> > > libpcap is already found and registered as a dependency by meson, and
> > > the dependency is already correctly used in librte_port. This line is
> > > just unnecessary.
> >
> > To be precise, the pcap PMD and the librte_port both declare their
> > dependency to libpcap with a line "ext_deps += pcap_dep"
> > and meson automatically adds this dependency to the pkg-config file
> > in the private section for static builds.
> > That's why it is not needed to add the dependency explicitly
> > in dpdk_extra_ldflags (involved in static build with pkg-config).
> >
> > > It also has the side effect of messing with the meson link line: dpdk
> >
> > Which "link line"?
> >
> > > link will be declared twice: manually and then through pkg-config. If
> >
> > What is "manually"?
> >
> > > you configure meson to prefer static linking over dynamic, this will
> >
> > No need to configure meson for that. Static linking can be tested with
> > make in an example. Please avoid messing with meson explanation
> > for application linking, it is already complicate enough :)
> >
> > > cause the build to fail on librte_port, since the pcap deps are not yet
> > > seen by the linker.
> >
> > Sorry it is not clear to me.
> > I think it would help to see a before/after effect on the link command.
> > Something like:
> >
> > before:
> >         Libs.private: -lpcap
> >         Requires.private: libpcap
> > after:
> >         Libs.private:
> >         Requires.private: libpcap
> >
> > [...]
> > > -     dpdk_extra_ldflags += '-lpcap'






      reply	other threads:[~2021-04-09  9:24 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-26  8:22 Gabriel Ganne
2021-03-26  9:30 ` Thomas Monjalon
2021-04-04  0:05 ` Dmitry Kozlyuk
2021-04-08 22:38 ` Thomas Monjalon
2021-04-09  8:31   ` Gabriel Ganne
2021-04-09  9:24     ` Thomas Monjalon [this message]

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=2147114.uPvM74KM6J@thomas \
    --to=thomas@monjalon.net \
    --cc=bruce.richardson@intel.com \
    --cc=david.marchand@redhat.com \
    --cc=dev@dpdk.org \
    --cc=gabriel.ganne@6wind.com \
    --cc=olivier.matz@6wind.com \
    --cc=thierry.herbelot@6wind.com \
    /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).