[PATCH] Link to -lssp when available (fixes mingw build)

Eli Zaretskii eliz@gnu.org
Wed Dec 18 23:12:00 GMT 2019


> From: "Christian Biesinger via gdb-patches" <gdb-patches@sourceware.org>
> Date: Wed, 18 Dec 2019 14:40:42 -0600
> Cc: gdb-patches <gdb-patches@sourceware.org>
> 
> BTW -- you mentioned a licensing issue with depending on DLLs. Doesn't
> libstdc++ and perhaps others have the same issue? Or does mingw.org
> link it statically?

libstdc++ and libgcc DLLs indeed have the same problem.  Which is why
I mentioned the fact that the binary of GDB 9.0.90 produced by the
MinGW build had dependencies on these two.  I solved that locally by
linking with "CXX='g++ -static-libstdc++ -static-libgcc'", but I
thought Pedro once said these dependencies shouldn't happen, and I
still hope we could understand why they suddenly appeared.

> My msys2/mingw64 gcc depends on these DLLs outside of SYSTEM32:
>         libpython3.8.dll => /mingw64/bin/libpython3.8.dll (0x70840000)
>         libwinpthread-1.dll => /mingw64/bin/libwinpthread-1.dll (0x64940000)
>         libgcc_s_seh-1.dll => /mingw64/bin/libgcc_s_seh-1.dll (0x61440000)
>         libstdc++-6.dll => /mingw64/bin/libstdc++-6.dll (0x6fc40000)

In general, any binary that depends on some DLLs and comes with those
DLLs needs to be accompanied by the sources of all the DLLs, to be
compatible with GPL.  In the above list, all the DLLs except Python
are part of GCC, so as long as the GCC sources are available, the
MinGW64 folks are okay.  I don't know how they deal with the problem
of providing the Python sources, though.

For the binaries I produce, I always try to link statically against
DLLs that come from GCC, because I don't want to distribute the
humongous GCC sources, and I don't want to provide a binary
distribution that is not self-contained (i.e. without those
problematic DLLs).



More information about the Gdb-patches mailing list