Build with posix threads depends on libwinpthread-1.dll

[petkapou]

Hi, we found out that binaries built with POSIX threads now depend on libwinpthread-1.dll. It is the only library not in windows/system32. The builds done earlier did not have this dependency.

To see a package with that dependency check out packages from tag: https://github.com/niXman/mingw-builds-binaries/releases/tag/13.2.0-rt_v11-rev0 (x86_64-13.2.0-release-posix-seh-msvcrt-rt_v11-rev0.7z)

$ ldd ./bin/cpp.exe
        ntdll.dll => /c/Windows/SYSTEM32/ntdll.dll (0x7ff81a210000)
        KERNEL32.DLL => /c/Windows/System32/KERNEL32.DLL (0x7ff819550000)
        KERNELBASE.dll => /c/Windows/System32/KERNELBASE.dll (0x7ff817860000)
        apphelp.dll => /c/Windows/SYSTEM32/apphelp.dll (0x7ff814310000)
        msvcrt.dll => /c/Windows/System32/msvcrt.dll (0x7ff8187f0000)
        libwinpthread-1.dll => /c/Studio/mingw64/bin/libwinpthread-1.dll (0x7ffff0ad0000)

We found some parts of code related to this, e.g. in scripts/mingw-w64-runtime-post.sh previously there was a condition for a build of a shared gcc. Now there is no such a condition and libwinpthreads is built differently.

# winpthreads
[[ $BUILD_SHARED_GCC == yes ]] && {
  cp -fv $RUNTIME_DIR/$BUILD_ARCHITECTURE-winpthreads-$RUNTIME_VERSION/bin/libwinpthread-1.dll $PREFIX/bin/ || { echo "13"; return 1; }
  cp -fv $RUNTIME_DIR/$BUILD_ARCHITECTURE-winpthreads-$RUNTIME_VERSION/bin/libwinpthread-1.dll $PREFIX/$TARGET/lib/ || { echo "14"; return 1; }
  cp -fv $RUNTIME_DIR/$BUILD_ARCHITECTURE-winpthreads-$RUNTIME_VERSION/lib/libwinpthread.dll.a $PREFIX/$TARGET/lib/ || { echo "15"; return 1; }
  cp -fv $RUNTIME_DIR/$BUILD_ARCHITECTURE-winpthreads-$RUNTIME_VERSION/lib/libpthread.dll.a $PREFIX/$TARGET/lib/ || { echo "16"; return 1; }
}
cp -fv $RUNTIME_DIR/$BUILD_ARCHITECTURE-winpthreads-$RUNTIME_VERSION/lib/libwinpthread.a $PREFIX/$TARGET/lib/ || { echo "17"; return 1; }
cp -fv $RUNTIME_DIR/$BUILD_ARCHITECTURE-winpthreads-$RUNTIME_VERSION/lib/libpthread.a $PREFIX/$TARGET/lib/ || { echo "18"; return 1; }
cp -fv $RUNTIME_DIR/$BUILD_ARCHITECTURE-winpthreads-$RUNTIME_VERSION/include/*.h $PREFIX/$TARGET/include/ || { echo "19"; return 1; }

As a result all binaries built with this GCC also depend on libwinpthread-1.dll.

I know about the change of threads in GCC, but I am not sure if or how it affected the POSIX threads.

Related issue: #622

Thank you.

[starg2]

I'd say this is by design.

If you don't want binaries built with gcc to depend on libwinpthread-1.dll, link everything statically or use win32 thread model.

[wassupxP]

Do you have any example of a build where everything is linked statically? I was not able to make it work. Built tooling was failing during runtime on missing dll.

It required some patches in the scripts though so I might have made some mistake there. (was trying to build x86_64-13.2.0-static-release-posix-seh-msvcrt-rt_v11-rev0 configuration)

[starg2]

Pass -static to the linker, and you should get a self-contained executable.

[wassupxP]

It didn't build. https://github.com/ugomancz/mingw-builds-binaries/actions/runs/8599000577/job/23560986589 Here is an example of the job.

[starg2]

Wait, are you trying to link everything statically into gcc itself? That will be hard with little gain. Why do you want that?

[petkapou]

When the binaries are not running in an msys shell which would add the dll to PATH, the dll needs to be copied everywhere,

My use case is that I have another bin folder outside of the built mingw and I generate multiple binaries on multiple locations in workspace during runtime. So then there is quite a lot of copies of the dll.

[starg2]

Sounds like you two have different goals.

Linking everything statically into your programs

If this is what you want, you can use the official binaries and don't have to build a toolchain yourself. Pass -static option to the linker when you link your programs, and you will get self-contained binaries. (Some people suggest -static-libgcc -static-libstdc++ but it doesn't affect libwinpthread-1.dll.)

You shouldn't build DLLs this way, or you will end up with multiple instances of the same runtime components in a single process, which will bite you later.

Linking everything statically into gcc itself

If this is what you want, you need to build a toolchain yourself. Pass whatever option you want and also --static-gcc to the build script. This should create self-contained gcc.exe, g++.exe etc.

Toolchains built this way will still create binaries linking to libwinpthread-1.dll and so on by default.

---

Please note that the above two are orthogonal. You can even choose both.

[SainoNamkho]

Linking everything statically into your programs

I guess the op needs just link only libwinpthread-1.dll statically only, keeping others as-is?

[mati865]

Linking shared libstdc++ with static winpthreads is probably not going to work. In that case they both should be linked statically.