Question about GCC license for commercial use

[Eli Zaretskii]

> Date: Wed, 16 Jul 2025 19:03:21 +0200
> Cc: qifan.zhou@xpeedic.com, gcc@gcc.gnu.org
> From: David Brown <david.brown@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.