[v3] meson: remove unnecessary explicit link to libpcap

Message ID 20210326082223.1398-1-gabriel.ganne@6wind.com (mailing list archive)
State Superseded, archived
Delegated to: Thomas Monjalon
Headers
Series [v3] meson: remove unnecessary explicit link to libpcap |

Checks

Context Check Description
ci/checkpatch warning coding style issues
ci/Intel-compilation success Compilation OK
ci/intel-Testing success Testing PASS
ci/travis-robot success travis build: passed
ci/github-robot success github build: passed
ci/iol-intel-Performance success Performance Testing PASS
ci/iol-abi-testing success Testing PASS
ci/iol-mellanox-Performance success Performance Testing PASS
ci/iol-testing success Testing PASS

Commit Message

Gabriel Ganne March 26, 2021, 8:22 a.m. UTC
  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.

It also has the side effect of messing with the meson link line: dpdk
link will be declared twice: manually and then through pkg-config. If
you configure meson to prefer static linking over dynamic, this will
cause the build to fail on librte_port, since the pcap deps are not yet
seen by the linker.

Signed-off-by: Gabriel Ganne <gabriel.ganne@6wind.com>
---
 config/meson.build | 1 -
 1 file changed, 1 deletion(-)
  

Comments

Thomas Monjalon March 26, 2021, 9:30 a.m. UTC | #1
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.
> 
> It also has the side effect of messing with the meson link line: dpdk
> link will be declared twice: manually and then through pkg-config. If
> you configure meson to prefer static linking over dynamic, this will
> cause the build to fail on librte_port, since the pcap deps are not yet
> seen by the linker.
> 
> Signed-off-by: Gabriel Ganne <gabriel.ganne@6wind.com>

When sending a new revision of a patch,
please add a changelog below "---"
and use --in-reply-to for threading, thanks.

> ---
>  config/meson.build | 1 -
>  1 file changed, 1 deletion(-)
  
Dmitry Kozlyuk April 4, 2021, 12:05 a.m. UTC | #2
2021-03-26 09:22 (UTC+0100), 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.
> 
> It also has the side effect of messing with the meson link line: dpdk
> link will be declared twice: manually and then through pkg-config. If
> you configure meson to prefer static linking over dynamic, this will
> cause the build to fail on librte_port, since the pcap deps are not yet
> seen by the linker.
> 
> Signed-off-by: Gabriel Ganne <gabriel.ganne@6wind.com>
> ---
>  config/meson.build | 1 -
>  1 file changed, 1 deletion(-)
> 
> diff --git a/config/meson.build b/config/meson.build
> index 66a2edcc47f5..95777cf33169 100644
> --- a/config/meson.build
> +++ b/config/meson.build
> @@ -183,7 +183,6 @@ if not pcap_dep.found()
>  endif
>  if pcap_dep.found() and cc.has_header('pcap.h', dependencies: pcap_dep)
>  	dpdk_conf.set('RTE_PORT_PCAP', 1)
> -	dpdk_extra_ldflags += '-lpcap'
>  endif
>  
>  # for clang 32-bit compiles we need libatomic for 64-bit atomic ops

This patch also simplifies future changes to discover libpcap on Windows.

Acked-by: Dmitry Kozlyuk <dmitry.kozliuk@gmail.com>
  
Thomas Monjalon April 8, 2021, 10:38 p.m. UTC | #3
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'
  
Gabriel Ganne April 9, 2021, 8:31 a.m. UTC | #4
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.

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

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

Best regards,

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'
>
>
>
>
  
Thomas Monjalon April 9, 2021, 9:24 a.m. UTC | #5
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'
  

Patch

diff --git a/config/meson.build b/config/meson.build
index 66a2edcc47f5..95777cf33169 100644
--- a/config/meson.build
+++ b/config/meson.build
@@ -183,7 +183,6 @@  if not pcap_dep.found()
 endif
 if pcap_dep.found() and cc.has_header('pcap.h', dependencies: pcap_dep)
 	dpdk_conf.set('RTE_PORT_PCAP', 1)
-	dpdk_extra_ldflags += '-lpcap'
 endif
 
 # for clang 32-bit compiles we need libatomic for 64-bit atomic ops