Closed petkapou closed 3 days ago
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.
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)
Pass -static
to the linker, and you should get a self-contained executable.
It didn't build. https://github.com/ugomancz/mingw-builds-binaries/actions/runs/8599000577/job/23560986589 Here is an example of the job.
Wait, are you trying to link everything statically into gcc itself? That will be hard with little gain. Why do you want that?
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.
Sounds like you two have different goals.
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.
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.
Linking everything statically into your programs
I guess the op needs just link only libwinpthread-1.dll
statically only, keeping others as-is?
Linking shared libstdc++ with static winpthreads is probably not going to work. In that case they both should be linked statically.
Hi, we found out that binaries built with POSIX threads now depend on
libwinpthread-1.dll
. It is the only library not inwindows/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
)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.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: https://github.com/niXman/mingw-builds/issues/622
Thank you.