Erik van Pienbroek
erik at vanpienbroek.nl
Fri Feb 20 15:51:09 UTC 2009
Op vrijdag 20-02-2009 om 18:13 uur [tijdzone +0300], schreef Alexey
> why don't many mingw32-xxx packages provide static (non-dll) versions of libraries ?
> For example no libz.a in mingw32-zlib. No libxerces-c.a in mingw32-xerces.
> Static linking makes a lot of sense with mingw.
> Unlike MSVC, Mingw (by default) links in msvcrt.dll which is *always*
> present in any Windows installation.
> Besides, Mingw *always* linkes in *static* libstdc++.a and libgcc.a.
> Therefore mingw-compiled executables generally have no dll dependenices,
> which is quite convenient.
> Moreover, .dlls usually don't make much sense with Mingw:
> when I distribute my mingw-compiled application, the chances
> that a user has another mingw-compiled application are quite
> small which defeats the purpose of using dynamic linking,
> static linking is usually more appropriate.
> But Mingw's no-dll-dependenices behavior is broken by the fact
> that mingw-* packages provide only dll versions of the libraries :-(
> And it's simply strange to have huge libstdc++.a
> statically linked into an executable and at the same time
> depend on tiny little libz1.dll
> BTW: Although static linking is rarely used in Linux,
> all *-devel Linux packages still have static versions of libraries...
+1 for having both shared and static MinGW libraries.
The main reason why they're banned from Fedora is because of security
issues. On Win32 this doesn't really make any sense as there is no
central package manager which can update libraries. At the moment,
software developers need to bundle the .dll's along with their
application anyway, so it doesn't really matter if these libraries are
shared or static.
In April last year, some changes went into GLib (and possibly other
GTK-related libs) for having static libraries support:
This will probably require a second compile when building the RPM's but
I think it's worth a shot.
Erik van Pienbroek
More information about the mingw