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
