DPDK patches and discussions
 help / color / mirror / Atom feed
From: Nick Connolly <nick.connolly@mayadata.io>
To: Dmitry Kozlyuk <dmitry.kozliuk@gmail.com>
Cc: Gabriel Ganne <gabriel.ganne@6wind.com>,
	Bruce Richardson <bruce.richardson@intel.com>,
	Kevin Laatz <kevin.laatz@intel.com>,
	dev@dpdk.org, olivier.matz@6wind.com, thierry.herbelot@6wind.com,
	"Dmitry Malloy (MESHCHANINOV)" <dmitrym@microsoft.com>,
	tal Shnaiderman <talshn@nvidia.com>,
	"Menon, Ranjit" <ranjit.menon@intel.com>,
	Thomas Monjalon <thomas@monjalon.net>,
	Tyler Retzlaff <roretzla@microsoft.com>
Subject: Re: [dpdk-dev] [PATCH v2 2/3] meson: use threads dependency as provided by meson
Date: Tue, 23 Mar 2021 13:35:52 +0000	[thread overview]
Message-ID: <7f3f5e7c-6731-1062-49ef-52e071a076d1@mayadata.io> (raw)
In-Reply-To: <20210323011800.2a50fde8@sovereign>


> Threads is a dummy dependency for Clang. For MinGW without pthread it still
> adds -pthread switch (and it comes to libdpdk.pc), but executable doesn't
> require pthread library to run. I can imagine DPDK built by MinGW without
> pthread be linked via pkg-config to an app built by MinGW with pthread, then
> -pthread switch will be added from libdpdk.pc. Do you think it's an issue?

Hi Dmitry,

I've done some experimenting with this change and agree that for Clang, 
-lpthread isn't
used when linking and it doesn't appear in libdpdk.pc.  It is added to 
the compile line,
as -pthread, but this doesn't seem to cause any issues.

Having said that, my test results above are with Meson 0.55.3. When I 
installed 0.49.0
to test it out, Meson was unable to complete the configuration, failing 
with:
> meson -Dexamples=helloworld
> ...
> Compiler for C supports arguments -D_XOPEN_SOURCE=600: YES
> Traceback (most recent call last):
>   File "mesonbuild\mesonmain.py", line 111, in run
> ...
>   File "mesonbuild\mesonlib.py", line 1222, in relpath
>   File "C:\python\lib\ntpath.py", line 560, in relpath
> TypeError: expected str, bytes or os.PathLike object, not NoneType

Unfortunately, I don't have time to pursue this further at the moment 
due to other
commitments, so I've reverted back to 0.55.3.

With MinGW, -pthread is added to compilation which doesn't seem to cause 
any issues.
In addition, -pthread is added to link and -lpthread appears in 
libdpdk.pc. My concerns
with this are:

 1. Adding -pthread to linking is an unnecessary dependency, even though
    it's
    relatively benign.

 2. Adding -lpthread to libdpdk.pc is more problematic. The application
    is almost
    certain to be using a threads library. If this is a 3rd party
    library, then the link
    command will potentially include two libraries defining the same
    exports.
    Which one takes precedence will depend upon the ordering in the
    application's
    build system which seems somewhat arbitrary given that the DPDK
    introduced
    dependency is not required.

I'd still advocate for:

if not is_windows
     threads_dep = dependency('threads')
endif

Regards,
Nick


  reply	other threads:[~2021-03-23 13:35 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-03-22 14:07 Gabriel Ganne
2021-03-22 14:07 ` [dpdk-dev] [PATCH v2 3/3] meson: remove unnecessary explicit link to libpcap Gabriel Ganne
2021-04-09  8:39   ` [dpdk-dev] [PATCH v4] " Gabriel Ganne
2021-04-09 12:25     ` [dpdk-dev] [PATCH v5] build: remove redundant libpcap link Thomas Monjalon
2021-04-14  9:41       ` Thomas Monjalon
2021-04-14 21:02         ` Dmitry Kozlyuk
2021-04-14 21:10           ` Thomas Monjalon
2023-07-16 17:19             ` Stephen Hemminger
2023-07-16 17:21     ` [dpdk-dev] [PATCH v4] meson: remove unnecessary explicit link to libpcap Stephen Hemminger
2021-03-22 16:04 ` [dpdk-dev] [PATCH v2 2/3] meson: use threads dependency as provided by meson Nick Connolly
2021-03-22 22:18   ` Dmitry Kozlyuk
2021-03-23 13:35     ` Nick Connolly [this message]
2021-03-23 21:21       ` Dmitry Kozlyuk
2021-03-23 22:17         ` Nick Connolly
2021-03-24  6:35           ` Gabriel Ganne

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=7f3f5e7c-6731-1062-49ef-52e071a076d1@mayadata.io \
    --to=nick.connolly@mayadata.io \
    --cc=bruce.richardson@intel.com \
    --cc=dev@dpdk.org \
    --cc=dmitry.kozliuk@gmail.com \
    --cc=dmitrym@microsoft.com \
    --cc=gabriel.ganne@6wind.com \
    --cc=kevin.laatz@intel.com \
    --cc=olivier.matz@6wind.com \
    --cc=ranjit.menon@intel.com \
    --cc=roretzla@microsoft.com \
    --cc=talshn@nvidia.com \
    --cc=thierry.herbelot@6wind.com \
    --cc=thomas@monjalon.net \
    /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).