[v2,2/3] meson: use threads dependency as provided by meson
Checks
Commit Message
meson guarantees this is portable, so this also allows us to remove a
is_windows switch.
Link: https://mesonbuild.com/howtox.html#enable-threads
Signed-off-by: Gabriel Ganne <gabriel.ganne@6wind.com>
---
config/meson.build | 5 +----
lib/librte_metrics/meson.build | 2 ++
lib/librte_telemetry/meson.build | 2 ++
3 files changed, 5 insertions(+), 4 deletions(-)
Comments
> meson guarantees this is portable, so this also allows us to remove a
> is_windows switch.
Hi Gabriel,
On Windows, there are at least three different compilation options:
* MinGW-w64 with posix threads
* MinGW-w64 with win32 threads (different download)
* Clang without threads support
The Windows EAL library doesn't use a threads package and instead uses
it's own wrappers around the native Windows system calls. Given that, I
believe the existing behaviour of not specifying the pthreads package
for a Windows build is correct and shouldn't be changed.
Regards,
Nick
2021-03-22 16:04 (UTC+0000), Nick Connolly:
> > meson guarantees this is portable, so this also allows us to remove a
> > is_windows switch.
> Hi Gabriel,
>
> On Windows, there are at least three different compilation options:
>
> * MinGW-w64 with posix threads
> * MinGW-w64 with win32 threads (different download)
> * Clang without threads support
>
> The Windows EAL library doesn't use a threads package and instead uses
> it's own wrappers around the native Windows system calls. Given that, I
> believe the existing behaviour of not specifying the pthreads package
> for a Windows build is correct and shouldn't be changed.
Hi Nick,
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?
> 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
2021-03-23 13:35 (UTC+0000), Nick Connolly:
[...]
> 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.
Agreed. In my tests it's "-pthread", not "-lpthread", but still.
See also comments here:
https://github.com/mesonbuild/meson/issues/553
Summary: dependency('threads') meaning is vague on Windows.
As a exotic case, I'm using NixOS which provides MinGW-w64 built with
mcfgthread (https://github.com/lhmouse/mcfgthread) and it doesn't even
recognize -pthread compiler flag, so this patch breaks cross-build for me.
> I'd still advocate for:
>
> if not is_windows
> threads_dep = dependency('threads')
> endif
It's more like, in lib/librte_telemetry/meson.build:
if not is_windows
ext_deps += threads_dep
endif
Gabriel, by the way, why is it needed for librte_metrics?
Isn't librte_telemetry enough since it's a dependency to EAL?
> Agreed. In my tests it's "-pthread", not "-lpthread", but still.
Agreed - I must have been distracted by the array of -l: arguments :-)
> It's more like, in lib/librte_telemetry/meson.build:
>
> if not is_windows
> ext_deps += threads_dep
> endif
It's not a big deal, but my thinking was that the library has a genuine
threads dependency, but in the Windows case this is satisfied by EAL
and so threads_dep can perhaps legitimately be empty. It also means
there's only one place where the decision is made regardless of the
number of dependencies.
Regards,
Nick
Hi Nick, Dmitry,
Thanks for the reviews.
I wrote this patch following the link issue I had with libpcap thinking it
was
"more of the same" ... which clearly it wasn't.
I had a closer look to what dependency('threads') generates and I agree
that it's not that well documented. From what I understand, it will always
the '-pthread' arg in the command line arguments, and then convert the
argument to the targeted environment (which might remove it if unsupported).
For librte_metrics, I am mistaken and the added dep should be removed.
I think that you are right to suggest keeping the "if not is_windows" test.
I will set up more test environments before submitting a new patch.
Best regards,
On Tue, Mar 23, 2021 at 11:17 PM Nick Connolly <nick.connolly@mayadata.io>
wrote:
>
> > Agreed. In my tests it's "-pthread", not "-lpthread", but still.
> Agreed - I must have been distracted by the array of -l: arguments :-)
> > It's more like, in lib/librte_telemetry/meson.build:
> >
> > if not is_windows
> > ext_deps += threads_dep
> > endif
> It's not a big deal, but my thinking was that the library has a genuine
> threads dependency, but in the Windows case this is satisfied by EAL
> and so threads_dep can perhaps legitimately be empty. It also means
> there's only one place where the decision is made regardless of the
> number of dependencies.
>
> Regards,
> Nick
>
@@ -113,10 +113,7 @@ if not is_windows
endif
# use pthreads if available for the platform
-if not is_windows
- add_project_link_arguments('-pthread', language: 'c')
- dpdk_extra_ldflags += '-pthread'
-endif
+threads_dep = dependency('threads')
# on some OS, maths functions are in a separate library
if cc.find_library('m', required : false).found()
@@ -4,6 +4,8 @@
sources = files('rte_metrics.c', 'rte_metrics_telemetry.c')
headers = files('rte_metrics.h', 'rte_metrics_telemetry.h')
+ext_deps += threads_dep
+
jansson = dependency('jansson', required: false, method: 'pkg-config')
if jansson.found()
dpdk_conf.set('RTE_HAS_JANSSON', 1)
@@ -3,6 +3,8 @@
includes = [global_inc]
+ext_deps += threads_dep
+
sources = files('telemetry.c', 'telemetry_data.c', 'telemetry_legacy.c')
headers = files('rte_telemetry.h')
includes += include_directories('../librte_metrics')