ForkI examined the latest MinGW binaries of Gettext 0.18.3.2-2 and
libiconv-1.14-4, with the purpose of finally upgrading to them from
the ancient versions I used till now, and found that almost all of the
DLLs (with the single exclusion of libiconv-2.dll) depend on
libgcc_s_dw2-1.dll and some depend also on libstdc++-6.dll.
This is a serious problem, because it means that if I want to
distribute programs built with dynamic dependency of these DLLs, I
must also distribute the GCC DLLs, and that in turn means I must
include the humongous GCC and libstdc++ source tarballs with any such
program I distribute. That's because the so-called "GCC runtime
library exception"[1], which allows to link programs with libgcc
without imposing the full requirements of GPL on that program, only
applies to static linking against libgcc, not dynamic linking against
libgcc shared library. As for libstdc++, there was never a similar
exception for it.
So the fact that MinGW now provides these libraries with those runtime
dependencies means it will not be practical for me to make my ports of
GPL software available (from the ezwinports site) in the form of
single self-contained zip files, each one of which includes all the
dependencies, because the above libraries cannot be included without
incurring problems whose solutions are either unsatisfactory or
impractical.
The solutions I could think of are:
1)distribute my ports without these DLLs, and tell users to install
the DLLs, including their dependencies, from the MinGW site --
this spells additional hassles for the users who install my ports
2)distribute the ports with these DLLs, and include GCC and libstdc++
source tarballs on the same site -- this is impractical,
especially since I will have to add more such tarballs as I
upgrade my GCC version (GPL requires to make available the exact
same sources as the ones used to build the binaries)
3)build my own ports of Gettext and libiconv without those runtime
dependencies -- this would require to produce my DLLs of Gettext
and libiconv under different names, to avoid "DLL hell" on the
users' systems, and would also require that I rebuild all the DLLs
that are already on ezwinports so that they depend on these
renamed DLLs (because otherwise programs that rely on those other
DLLs will still need Gettext and libiconv DLLs under their
original names) -- thus also quite impractical
4)statically link programs with Gettext and libiconv -- this is
possible for standalone programs, but in general not for libraries
There are more problems for my own system configuration, because to
use future MinGW GCC version, and also the libgccjit extension Keith
just made available at my request, I will have to have a configuration
where some programs must find the MinGW-provided DLLs of Gettext and
libiconv. So if I decide to go any way but 1) or 2) above, I will
need to have some complicated system setup to avoid DLL clashes -- and
so will any other user of MinGW with similar issues.
(I understand the rationale for the runtime dependencies on DLLs --
the wish to be able to propagate C++ exceptions across DLLs -- but the
problems the DLL solution creates for distributing binaries of
anything but GCC itself are very serious, as I tried to explain
above.)
Does anyone see any practical solution that avoids the issues
mentioned above? Am I missing something which makes the issues go
away?
TIA
[1] https://www.gnu.org/licenses/gcc-exception-3.1.en.html