Static linking makes a lot of sense with mingw.

BTW: Although static linking is rarely used in Linux, all *-devel Linux packages still have static versions of libraries...

Hi, 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...

On Fri, Feb 20, 2009 at 04:51:09PM +0100, Erik van Pienbroek wrote: > +1 for having both shared and static MinGW libraries. We'd need to have -static subpackages, as per Fedora policy. This is loads and loads of work which I don't intend to do myself ...

Hi, +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.

On Fri, Feb 20, 2009 at 06:13:28PM +0300, Alexey Pushkin wrote: [...] The general Fedora policy is to package up dynamic libraries in preference to static libraries, and this is the policy we have pursued. You'll have to take up any issues with Fedora (good luck!)

We also have the nsiswrapper tool which makes packaging DLLs for distribution particularly easy, because by default nsiswrapper will find and package any dependent DLLs that you need.

This, however, seems to be a bug: > 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

Rich.

On Fri, Feb 20, 2009 at 07:04:23PM +0300, Alexey Pushkin wrote: > Richard W.M. Jones wrote: >> The general Fedora policy is to package up dynamic libraries in >> preference to static libraries, and this is the policy we have >> pursued. You'll have to take up any issues with Fedora (good luck!) > Windows is different from Linux and IMHO the reasoning > behind this policy is not applicable to Mingw stuff. Perhaps it is different, but this is something that has to be discussed with Fedora, FPC and FESCO. Remember to take along your flameproof suit.

I'm not convinced anyway: First of all I think there _is_ a security issue, for example with the few executables that we do distribute. Secondly the virt people need DLLs and aren't really interested in doing the work for static linking, since we would never use it.

On Fri, Feb 20, 2009 at 1:25 PM, Alexey Pushkin <alexey.pushkin(a)mererand.com&gt; wrote: > Because, with dynamic linking they'll anyway end up installing > private copies of all the dlls together with the executable > somewhere under Program_Files/MySuperApp/bin. I agree that static linking is much more preferred on a windows platform, even for performance reasons. I will note, however, that there is possibly one scenario where shipping a dll is desirable. That is, when you have multiple executables in your "Super App", and they all link to the same lib. In that case, having them all link to a dll that you deliver has advantages (especially if we get delayed loading to work). Plugin management for an app is another place where dll support is desirable. All of these, I warrant, are exceptions. I still agree that the default should be static.

_______________________________________________ fedora-mingw mailing list fedora-mingw(a)lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/fedora-mingw

Let's just recap the facts, in case there was confusion about it ... (1) The default remains to provide dynamic libraries. There's no discussion on this point, because even if I thought it was a good idea to change (which I don't), Fedora policy would prevent it. (2) IMHO there is no realistic chance to change Fedora policy, although you are welcome to try. (3) Fedora policy allows static libraries to be provided in *-static subpackages. http://fedoraproject.org/wiki/Packaging/Guidelines#Packaging_Static_Libra... (4) *-static subpackages don't happen by magic. You have to find someone to do this work for you, or do it yourself. (5) Post your patches to this list, for the usual review / submission process.

Hope that's clear. Rich.

(4) *-static subpackages don't happen by magic. You have to find someone to do this work for you, or do it yourself. (5) Post your patches to this list, for the usual review / submission process.