meson: don't add -pthread to static linking flags on Windows
#3931
Conversation
|
Is there anything I can do to help this move forward? |
|
It's mostly a matter of finding someone for the review. In my understanding, this PR is helpful when using It seems this is a combination we don't have in CI, hence we can't "witness" the impact of this change. |
|
It's helpful for building zstd for Windows with MinGW, possibly via cross-compilation. Many application stacks will already use winpthreads, either because something in the stack uses pthreads explicitly, or because something uses C/C++ thread intrinsics and MinGW-w64 is configured to implement those via pthreads. In that case, zstd's current behavior amounts to harmless overlinking. My stack uses MinGW-w64 configured to implement intrinsics via Win32 primitives (a less common configuration), and does not otherwise use or ship winpthreads, so the current behavior produces an unsatisfied dependency. If desired, I can see about adding a short test job for MinGW + Meson, or provide manual build instructions for verification. |
|
That would be a good idea. |
Meson always returns -pthread in dependency('threads') on non-MSVC
compilers. On Windows we use Windows threading primitives, so we don't
need this. Avoid adding -pthread to libzstd's link flags, either as a
Meson subproject or via pkg-config Libs.private, so the application
doesn't inadvertently depend on winpthreads.
Add a Meson MinGW cross-compile CI test that checks for this. It turns
out that pzstd fails to build in that environment, so have the test
skip building contrib for now.
bgilbert
changed the title
-pthread on Windows-pthread to static linking flags on Windows
|
Added a CI job. It turns out that the DLL doesn't end up linked against winpthreads, so the problem is limited to the linker flags we tell applications to use when linking with our static library. I've updated the PR description and commit message accordingly. |
|
I assume the last remaining CI error ( |
|
Yes, looks like the Cygwin failure is a transient network issue. |
|
Is this ready to go in? |
yep |
Meson always returns -pthread in dependency('threads') on non-MSVC
compilers. On Windows, zstd uses Windows threading primitives, so we
don't need this. Avoid adding -pthread to libzstd's link flags, either as
a Meson subproject or via pkg-config Libs.private, so the application
doesn't inadvertently depend on winpthreads.
Merged upstream in facebook/zstd#3931.
Meson always returns -pthread in dependency('threads') on non-MSVC
compilers. On Windows, zstd uses Windows threading primitives, so we
don't need this. Avoid adding -pthread to libzstd's link flags, either as
a Meson subproject or via pkg-config Libs.private, so the application
doesn't inadvertently depend on winpthreads.
Merged upstream in facebook/zstd#3931.
Meson always returns -pthread in dependency('threads') on non-MSVC
compilers. On Windows, zstd uses Windows threading primitives, so we
don't need this. Avoid adding -pthread to libzstd's link flags, either as
a Meson subproject or via pkg-config Libs.private, so the application
doesn't inadvertently depend on winpthreads.
Merged upstream in facebook/zstd#3931.
Meson always returns
-pthreadindependency('threads')on non-MSVC compilers. On Windows we use Windows threading primitives, so we don't need this. Avoid adding-pthreadto libzstd's link flags, either as a Meson subproject or via pkg-configLibs.private, so the application doesn't inadvertently depend on winpthreads.Add a Meson MinGW cross-compile CI test that checks for this. It turns out that
pzstdfails to build in that environment, so have the test skip buildingcontribfor now.