Re: static libraries
Original Message Subject: static libraries From: Alexey Pushkin alexey.push...@mererand.com To: fedora-mingw@lists.fedoraproject.org Date: 02/20/2009 09:13 AM Static linking makes a lot of sense with mingw. Yes, but it should be optional. You should fix your Makefiles to pull the *.dll files you need from the mingw package and ship them if you are sure your target users don't have them. At least that's what I'm doing. BTW: Although static linking is rarely used in Linux, all *-devel Linux packages still have static versions of libraries... Not all... Fedora has been aggressively moving away from static libraries and have even stopped shipping *.a files in *-devel packages. krb5-devel for example. ___ fedora-mingw mailing list fedora-mingw@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/fedora-mingw
Re: static libraries
Michael Cronenworth wrote: Original Message Subject: static libraries From: Alexey Pushkin alexey.push...@mererand.com To: fedora-mingw@lists.fedoraproject.org Date: 02/20/2009 09:13 AM Static linking makes a lot of sense with mingw. Yes, but it should be optional. Surely it should be optional, but now this option simply doesn't exist :-( You should fix your Makefiles to pull the *.dll files you need from the mingw package and ship them if you are sure your target users don't have them. At least that's what I'm doing. This of course works with executables but if you're distributing a .dll things get much worse. In my experience customers just hate the fact that in addition to your .dll they also need a bunch of dependency .dlls. And even if they accept this, they start making all possible mistakes which eats enormous amount of time. ___ fedora-mingw mailing list fedora-mingw@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/fedora-mingw
Re: static libraries
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. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones Read my OCaml programming blog: http://camltastic.blogspot.com/ Fedora now supports 68 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora ___ fedora-mingw mailing list fedora-mingw@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/fedora-mingw
Re: static 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 ... Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top ___ fedora-mingw mailing list fedora-mingw@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/fedora-mingw
Re: static libraries
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. Since the .dlls will be bundled with an application anyways, .dlls bring only negative effects: (a) bigger total file size (b) runtime relocations (c) more complicated installation ___ fedora-mingw mailing list fedora-mingw@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/fedora-mingw
Re: static libraries
Op vrijdag 20-02-2009 om 15:54 uur [tijdzone +], schreef Richard W.M. Jones: 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 ... I can help with this if wanted ___ fedora-mingw mailing list fedora-mingw@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/fedora-mingw
Re: static libraries
Richard W.M. Jones wrote: 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!) Windows is different from Linux and IMHO the reasoning behind this policy is not applicable to Mingw stuff. 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. If you distribute a .dll (as opposed to executables) all the installer wisdom doesn't help much. Users just want to have your .dll with no dependencies, no matter what. And even if they accept dependencies, they'll start making incredible amount of mistakes. 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 I'm afraid you're going to make libstdc++ and libgcc dynamic :-( If you don't keep an option to have them static I'll not be able to use Fedora packages anymore :-( Rich. ___ fedora-mingw mailing list fedora-mingw@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/fedora-mingw
Re: static libraries
Richard W.M. Jones wrote: 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 ... this is required for native packages not for mingw packages we can also include this exception in mingw packaging guide. may be we can wait a little bit when a new packaging guide will created/accepted for all of our target platform and in this guideline add this exception too. -- Levente Si vis pacem para bellum! ___ fedora-mingw mailing list fedora-mingw@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/fedora-mingw
Re: static libraries
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. Anyway, if you have patches to make -static subpackages, post them for review on this list. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-p2v converts physical machines to virtual machines. Boot with a live CD or over the network (PXE) and turn machines into Xen guests. http://et.redhat.com/~rjones/virt-p2v ___ fedora-mingw mailing list fedora-mingw@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/fedora-mingw
Re: static libraries
Richard W.M. Jones wrote: 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. Well, I'm not really associated with Fedora in any way... Just a happy Fedora+Mingw user :-) 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. Sure, in many cases one would want dynamic linking. But many developers would prefer static versions. 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. Which (a) defeats the purpose of dynamic linking (b) increases total file size (c) complicates installation and at the same time doesn't bring any benefits. And for people like me, who also need to distribute their own DLLs, dynamic linking is simply a non-solution. ___ fedora-mingw mailing list fedora-mingw@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/fedora-mingw
Re: static libraries
On Fri, Feb 20, 2009 at 1:25 PM, Alexey Pushkin alexey.push...@mererand.com 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@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/fedora-mingw
Re: static libraries
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_Libraries (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. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/ ___ fedora-mingw mailing list fedora-mingw@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/fedora-mingw
Re: static libraries
Richard W.M. Jones wrote: 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_Libraries (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. Alright, next week I'll try to build libz-static and xerces-static (I personally need these 2 packages :-) One more question: Somebody in this thread mentioned that an exception could be made for mingw packages, so that we won't need separate -static packages. This will be (a) less work for maintainers (b) IMHO more convenient for users Do you think it's realistic ? Hope that's clear. Rich. ___ fedora-mingw mailing list fedora-mingw@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/fedora-mingw
Re: static libraries
On Fri, Feb 20, 2009 at 11:07:33PM +0300, Alexey Pushkin wrote: One more question: Somebody in this thread mentioned that an exception could be made for mingw packages, so that we won't need separate -static packages. This will be (a) less work for maintainers (b) IMHO more convenient for users I don't think it'll be any less work for maintainers. Adding a subpackage to an RPM spec file is pretty easy. Fedora policy demands the split, so as you say we would have to get an exception, but it's not a battle I'm personally too happy about taking on. No one was here for the epic battle to get MinGW added to Fedora in the first place, but it wasn't pleasant at the time. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones Read my OCaml programming blog: http://camltastic.blogspot.com/ Fedora now supports 68 OCaml packages (the OPEN alternative to F#) http://cocan.org/getting_started_with_ocaml_on_red_hat_and_fedora ___ fedora-mingw mailing list fedora-mingw@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/fedora-mingw
Re: static libraries (patches for GLib, ATK and Pango)
Op vrijdag 20-02-2009 om 19:55 uur [tijdzone +], schreef Richard
W.M. Jones:
(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.
Here are patches for GLib, ATK and Pango.
For ATK, it is a pretty straightforward --enable-static flag.
For Pango a patch needs to be applied as the static build of Pango is
intentionally disabled in the configure script. However, according to
the SVN logs of Pango, this change was done almost 5 years ago [1] and I
haven't found any strange behaviour with the static build so I think it
is safe to apply.
For GLib there's also a small difference in the header file
glibconfig.h. See the patch for full details.
Regards,
Erik van Pienbroek
[1]: http://svn.gnome.org/viewvc/pango?view=revisionrevision=1117
--- mingw32-atk.spec.orig 2009-02-20 21:19:20.555682663 +0100
+++ mingw32-atk.spec 2009-02-20 22:31:47.909956339 +0100
@@ -6,7 +6,7 @@
Name: mingw32-atk
Version:1.25.2
-Release:5%{?dist}
+Release:6%{?dist}
Summary:MinGW Windows Atk library
License:LGPLv2+
@@ -36,12 +36,20 @@
MinGW Windows Atk library.
+%package static
+Summary:Static version of the MinGW Windows Atk library
+Requires: %{name} = %{version}-%{release}
+
+%description static
+Static version of the MinGW Windows Atk library.
+
+
%prep
%setup -q -n atk-%{version}
%build
-%{_mingw32_configure} --disable-static
+%{_mingw32_configure} --enable-static --enable-shared
make %{?_smp_mflags}
@@ -76,8 +84,14 @@
%{_mingw32_libdir}/libatk-1.0.la
%{_mingw32_libdir}/pkgconfig/atk.pc
+%files static
+%{_mingw32_libdir}/libatk-1.0.a
+
%changelog
+* Fri Feb 20 2009 Erik van Pienbroek i...@nntpgrab.nl - 1.25.2-6
+- Added -static subpackage
+
* Fri Feb 6 2009 Richard W.M. Jones rjo...@redhat.com - 1.25.2-5
- Include license file.
--- mingw32-glib2.spec.orig 2009-02-20 17:23:15.875672929 +0100
+++ mingw32-glib2.spec 2009-02-20 21:51:08.919675233 +0100
@@ -6,7 +6,7 @@
Name: mingw32-glib2
Version:2.19.5
-Release:3%{?dist}
+Release:4%{?dist}
Summary:MinGW Windows GLib2 library
License:LGPLv2+
@@ -41,6 +41,12 @@
%description
MinGW Windows Glib2 library.
+%package static
+Summary:Static version of the MinGW Windows GLib2 library
+Requires: %{name} = %{version}-%{release}
+
+%description static
+Static version of the MinGW Windows GLib2 library.
%prep
%setup -q -n glib-%{version}
@@ -52,14 +58,61 @@
%build
-%{_mingw32_configure} --disable-static
-make %{?_smp_mflags}
-
+# GLib can't build static and shared libraries in one go, so we
+# build GLib twice here
+mkdir build_static
+pushd build_static
+%{_mingw32_configure} --disable-shared --enable-static
+make %{?_smp_mflags}
+popd
+
+mkdir build_shared
+pushd build_shared
+%{_mingw32_configure} --disable-static
+make %{?_smp_mflags}
+popd
%install
rm -rf $RPM_BUILD_ROOT
-make DESTDIR=$RPM_BUILD_ROOT install
+# First install all the files belonging to the shared build
+make -C build_shared DESTDIR=$RPM_BUILD_ROOT install
+
+# Install all the files from the static build in a seperate folder
+# and move the static libraries to the right location
+make -C build_static DESTDIR=$RPM_BUILD_ROOT/build_static install
+mv $RPM_BUILD_ROOT/build_static%{_mingw32_libdir}/*.a $RPM_BUILD_ROOT%{_mingw32_libdir}
+
+# Manually merge the libtool files
+sed -i s/old_library=''/old_library='libgio-2.0.a'/ $RPM_BUILD_ROOT%{_mingw32_libdir}/libgio-2.0.la
+sed -i s/old_library=''/old_library='libglib-2.0.a'/ $RPM_BUILD_ROOT%{_mingw32_libdir}/libglib-2.0.la
+sed -i s/old_library=''/old_library='libgobject-2.0.a'/ $RPM_BUILD_ROOT%{_mingw32_libdir}/libgobject-2.0.la
+sed -i s/old_library=''/old_library='libgmodule-2.0.a'/ $RPM_BUILD_ROOT%{_mingw32_libdir}/libgmodule-2.0.la
+sed -i s/old_library=''/old_library='libgthread-2.0.a'/ $RPM_BUILD_ROOT%{_mingw32_libdir}/libgthread-2.0.la
+
+# There's also a small difference in the file glibconfig.h between the
+# shared and the static build:
+#
+#diff -ur shared/usr/i686-pc-mingw32/sys-root/mingw/lib/glib-2.0/include/glibconfig.h static/usr/i686-pc-mingw32/sys-root/mingw/lib/glib-2.0/include/glibconfig.h
+#--- shared/usr/i686-pc-mingw32/sys-root/mingw/lib/glib-2.0/include/glibconfig.h 2009-02-20 17:34:35.735677022 +0100
+#+++ static/usr/i686-pc-mingw32/sys-root/mingw/lib/glib-2.0/include/glibconfig.h 2009-02-20 17:33:35.498932269 +0100
+#@@ -92,7 +92,8 @@
+#
+# #define G_OS_WIN32
+# #define G_PLATFORM_WIN32
+#-
+#+#define GLIB_STATIC_COMPILATION 1
+#+#define GOBJECT_STATIC_COMPILATION 1
+#
+# #define G_VA_COPY va_copy
+#
+# However, we can't merge this change as it is situation-dependent...
+#
+# Developers using the static build of GLib need to add -DGLIB_STATIC_COMPILATION
+# and
Re: static libraries (patches for GLib, ATK and Pango)
On Fri, Feb 20, 2009 at 10:43:05PM +0100, Erik van Pienbroek wrote: Op vrijdag 20-02-2009 om 19:55 uur [tijdzone +], schreef Richard W.M. Jones: (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. Here are patches for GLib, ATK and Pango. For ATK, it is a pretty straightforward --enable-static flag. For Pango a patch needs to be applied as the static build of Pango is intentionally disabled in the configure script. However, according to the SVN logs of Pango, this change was done almost 5 years ago [1] and I haven't found any strange behaviour with the static build so I think it is safe to apply. For GLib there's also a small difference in the header file glibconfig.h. See the patch for full details. Thanks - those are all ACKed and applied with a few minor fixes. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-top is 'top' for virtual machines. Tiny program with many powerful monitoring features, net stats, disk stats, logging, etc. http://et.redhat.com/~rjones/virt-top ___ fedora-mingw mailing list fedora-mingw@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/fedora-mingw
