All of lore.kernel.org
 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 [dpdk-dev] [PATCH v3] meson: remove unnecessary explicit link to libpcap 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.