> Date: Wed, 16 Jul 2025 19:03:21 +0200 > Cc: qifan.z...@xpeedic.com, gcc@gcc.gnu.org > From: David Brown <david.br...@hesbynett.no> > > >> Well they didn't ask about distributing the DLLs :-) > > > > They did, indirectly: programs compiled by MinGW GCC are linked > > against libgcc and libstdc++ import libraries, and thus have run-time > > dependency on these DLLs. Unless the Windows loader can find them on > > the end-user's machine, it will refuse to run the program. So if they > > intend to distribute their programs, they will have to distribute > > these DLLs with it (or ask the end users to install the DLLs by > > themselves, which would mean the program is not self-contained). > > Why would you not simply statically link to these libraries? I don't > use MinGW (or Mingw-w64) very often, and have not distributed programs > compiled with them. But as far as I know, static linking should work > fine - then you don't need to distribute the DLL's, you are covered by > the GPL license exceptions (IANAL), you have no risk of "DLL hell" or > compatibility issues, and the binaries are likely to be a little faster > since the linkage is static.
Static linking works, but it doesn't solve the problem, and adds some new ones: . if the program is linked with other libraries, which were dynamically linked against those libraries (many are), you will still have the run-time dependency; worse, libgcc linked statically will conflict with the dynamically-linked one (they will both run the dtors when the program exits), which will call 'abort' at exit . statically linking C++ programs against libstdc++ prevents exception propagation across libraries, which is not a good idea for a C++ program There might be other problems, I don't remember all the details. I do remember that at the time I tried to use static linking against these two libraries, but eventually gave up, because it caused too many issues.
