Proposal: drop the hard dependency on mingw32-gettext from mingw32-glib2
by Erik van Pienbroek
Hi,
Recently I was browsing the upstream GTK website and I noticed that
upstream has used a special trick to build the Win32 binaries for GLib.
In order to make the dependency on gettext a soft one they used a small
static wrapper library called libproxy-intl [1]. With this wrapper
library the GLib DLL doesn't depend directly anymore on libintl-8.dll
(from mingw32-gettext). The wrapper library makes the hard dependency a
runtime one. This means that if libintl-8.dll is bundled with the
application then gettext translations will be used, otherwise nothing
gets translated.
I'd like to propose that we apply this change as well in our Fedora
MinGW toolchain.
Such a change consists of the following smaller changes:
- Bundle the libproxy-intl code (1 .c file and 1 .h file) in
the mingw32-gettext srpm as additional source files
- Compile the libproxy-intl code with these 2 instructions:
%{_mingw32_cc} -c libintl.c -o libintl.o -I.
%{_mingw32_ar} rc libintl.a libintl.o
- Replace the files libintl.{a,.dll.a,.la} generated by the
gettext compilation with the libintl.a file from libproxy-intl.
This makes any binary which tries to link against mingw32-gettext
using '-lintl' have a soft-dependency on libintl.
After this a simple rebuild of mingw32-glib2 should be sufficient enough
to make mingw32-gettext a soft dependency.
Next to glib2 there are also some other packages which have a hard
dependency on libintl-8.dll:
$ repoquery --whatrequires 'mingw32(libintl-8.dll)'
mingw32-atk-0:1.32.0-1.fc14.noarch
mingw32-gdk-pixbuf-0:2.22.0-1.fc14.noarch
mingw32-glib2-0:2.26.0-1.fc14.noarch
mingw32-gnutls-0:2.6.4-3.fc13.noarch
mingw32-gtk-vnc-0:0.4.1-1.fc14.noarch
mingw32-gtk2-0:2.22.0-1.fc14.noarch
mingw32-gtkhtml3-0:3.32.0-1.fc14.noarch
mingw32-gvnc-0:0.4.1-1.fc14.noarch
mingw32-hunspell-0:1.2.8-11.fc12.noarch
mingw32-libglade2-0:2.6.4-4.fc12.noarch
mingw32-libidn-0:1.14-5.fc12.noarch
Most of these packages (if not all) don't use gettext directly, but get
linked against gettext because of it being mentioned in glib2's
pkgconfig and .la files. A rebuild should be sufficient to replace the
hard dependencies on those packages by soft ones. However, in order to
prevent the libproxy-intl functions from being exported in other DLL's
(as mentioned on [1]) I think it's better drop the reference to libintl
from glib2's pkgconfig and .la files. As most of the packages mentioned
above don't use gettext directly, but the GLib gettext functions to
handle translations this shouldn't cause any major problems.
As the glib2 headers depend on the libintl.h header a 'Requires:
mingw32-gettext' also needs to be added to the mingw32-glib2 package.
I already applied these changes in a testing repository for a generic
cross compiler framework (coming soon!) [2][3] and it works fine there.
Another thing GTK upstream has done in their Win32 binaries is using
win-iconv instead of GNU iconv. I just put up a review request for
mingw32-win-iconv at [4]. Could somebody please review that package?
Does everybody agree to these changes?
Kind regards,
Erik van Pienbroek
[1]: http://www.gtk.org/download-windows.html
[2]: http://svn.openftd.org/svn/fedora_cross
[3]: http://svn.openftd.org/viewvc/Fedora%20Cross%20Compiler%
20Framework/
[4]: https://bugzilla.redhat.com/show_bug.cgi?id=642208
12 years, 11 months
leaving the project
by Michael [Plouj] Ploujnikov
Hello fedora-mingw people,
I haven't really been active with the mingw project lately. In fact,
I've stopped using Fedora as my main distribution. As a result I've
decided that I should probably step down rather than being a dormant
"contributor".
It would be nice if someone takes ownership of my packages
(http://koji.fedoraproject.org/koji/userinfo?userID=986)"
mingw32-libtiff and mingw32-physfs. Also, there is current a security
bug assigned to me that needs to be taken care of:
https://bugzilla.redhat.com/show_bug.cgi?id=689575.
I'm sorry to have to bring you this sad news. I wish you and the
Fedora project as a whole all the best.
- Michael Ploujnikov
13 years
[Bug 587818] missing %{__strip} corrupts mingw binaries during rpmbuild
by Red Hat Bugzilla
Please do not reply directly to this email. All additional
comments should be made in the comments box of this bug.
https://bugzilla.redhat.com/show_bug.cgi?id=587818
Vassili Leonov <vleolml(a)gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |vleolml(a)gmail.com
--- Comment #4 from Vassili Leonov <vleolml(a)gmail.com> 2011-03-29 05:46:19 EDT ---
Another manifestation of this bug, confirmed on fresh, updated as of 2011.03.29
F14 i386, is that when some (not all!) RPMS for ming32 are rebuilt, and when
error messages of this kind:
strip:/home/vleo/rpmbuild/BUILDROOT/mingw32-gsm-1.0.14-mt.fc14.i386/usr/i686-pc-mingw32/sys-root/mingw/lib/libgsm.a(libgsm_la-add.o):
Unable to recognise the format of file: File format not recognized
from the rpmbuild process are ignored, other packages dependent on these
improperly built RPMs will fail to build as well. For example, ming32-libgsm
built without redhat-rpm-config would not be usable for ffmpeg build, with
configure message like this (tail config.log):
i686-pc-mingw32-gcc -o /tmp/ffconf.kcYisU51.exe /tmp/ffconf.7bQViuE8.o -lm
-lpthreadGC2 -lbz2 -lz -lpsapi -lgsm
/usr/i686-pc-mingw32/sys-root/mingw/lib/libgsm.dll.a: could not read symbols:
Archive has no index; run ranlib to add one
ERROR: libgsm not found
I don't know what priority should be, but SEVERITY for this bug should be
higher, because of its indirect effects.
--
Configure bugmail: https://bugzilla.redhat.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
13 years
MinGW64 i686 Packages
by Chris Bisnett
I've been using the the mingw64 packages for Fedora for a while now and they
work great, thanks Erik. I've even been meaning to post a tutorial about
using the cross compiler with Eclipse and how to setup remote debugging
using gdb-server.
The only problem I have run into so far is that there are no i686 packages.
My netbook is only x86 but I would still like to be able to compile for
Win64. I'm not sure if this can be done, but since it's a cross compiler I
would think that it just needs to be built for i686. If it is possible and
isn't a big deal, let me know and I'll even build the packages so they can
be added to the repo.
I really like being able to develop Windows executable on my Linux machines
and I really appreciate the time everyone has given to this project.
- Chris Bisnett
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v2.0.16 (GNU/Linux)
mQENBE1pXBwBCAC1hmk7MG5pRAAxxl8k1KPlPZdxbqhw1kwYspkWnpz9lljRT2ql
30fws7C+XGFRj7CDP/cnrE8gHwZLyGNZFvL/nkUGGkYSXfZ+/5PLi2q5AsqPX9y9
3KOyEKeHEQ/J0Z63Rs/Jzr/xThAog9X7tIxOgQlxa3InOsaeYt5xW+CR0g6G31FA
ZO3emuIwgVZD8WSPdEHZXlZOug3AAPQM1aJJbmhihbiBSE1R1Bd7TXuaXJquIwGr
DjQynMMm0pN4g7NPCc1KuSv3VpZkjYG98GC6D9Y3CjFpL/rrbCCGM6oyLM9hyNt4
vRE1T2jJ3kFGpbiKbA5hloPTEXYM/dQA8GIFABEBAAG0IkNocmlzIEJpc25ldHQg
PGNiaXNuZXR0QGdtYWlsLmNvbT6JAT4EEwECACgFAk1pXBwCGwMFCQKymWQGCwkI
BwMCBhUIAgkKCwQWAgMBAh4BAheAAAoJEF6W7OyjNOKYwSgH/3AMJtA1RGQhmv2c
5nbb7wtDArgboU1saXxryZRYtVMTKcu6cabAuIwtxtWhXz5qCVdaoW5wqHsByTgZ
sxLmv8muzFdpcgBjP+LgowOL/Fxbhnec9gaI2Hmzimu8i/y2CfUeSleYmWmv7lT9
DIRe4QOmr4xzOqzFZ2u8fYz6pg7q764fMWaTDXM2vGun/44dPBR9xOW4gq4fTWHl
UTwQMNVN8btQNq1mCqRvylVKipQfMCmcM6JpBjezSeg8KJxwJ4DPMQHXaY7WT13s
DS2cfpXd7u8aDQ9A2QcVWN4wmfLiSofrIyQGszjQqTSVOZrJhOx4GLoAVryZgbtk
o2pTymq5AQ0ETWlcHAEIAKQmKFUM2UbfbHdWvfE2/xU/Cv0EXeGEcQ0SM2PlQw1P
539yDI4RB7hqRoXaHwk3sQobCELP69bYLe23ok8bYwIeagIQyCh62tUHs11eLLh7
2mcvCmwUoD3an54f9EAIV2vM6BieLSWmLHZOsmMQO8vXbnKifenXTny0M5q1CGZV
aXrrY863gCajrxYBJQVuM754Moy8rhy1wPx6ipSJfzVLwHiEoHO6YmH/bdl9I484
zwdVaNTMdYgcY9lgFveZ7AVdAgTUvbR/VHAbRpZOxzpQ97RliklLpttKjcRQTddp
qEcFHcI7xp1qKiuG3STJpXWw285JY1slOIGsCxI6u4MAEQEAAYkBJQQYAQIADwUC
TWlcHAIbDAUJArKZZAAKCRBeluzsozTimASHB/9dNXpO/ktodVy9zDAuXSB1+HC1
3fKWtg5OfYb/U6i1Eub7A2bCJUKtxz5f2p8H4P4h8Pq28Vhq1yUyoidxqb1udnMd
pRSZ9e3KLf1LeLMYFK3CeKt/hljk/nzrlABLdEHXaq6SSBrCVNNmIzlCxtw3ppDp
odOjPQ4lG+a2tUD8WvetoIklJI7EZKfqe5pG2QE1bKB/LlrOjRUxkO9B22j/EzsS
v4iJ3aLuZWQ00x3ZheDYV3RFbqJxt+ajf5MkClafmS1G95C/NoabDJBO/xvZN55I
iGPVBRLMknlOzpQVqhuz0vrhAyC6z95joshBNhkc5ZDDxagIgH612I8Wx4lw
=sL6E
-----END PGP PUBLIC KEY BLOCK-----
13 years, 1 month
[mingw32-binutils] Spec file cleanups
by Kalev Lember
commit eeaebcf37c6a9cef314ae50f8af884d41dc85346
Author: Kalev Lember <kalev(a)smartlink.ee>
Date: Thu Mar 17 15:08:41 2011 +0200
Spec file cleanups
Don't own the /usr/i686-pc-mingw32/bin/ directory and use %defattr(-,root,root,-)
mingw32-binutils.spec | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
---
diff --git a/mingw32-binutils.spec b/mingw32-binutils.spec
index 80a49bd..eff173e 100644
--- a/mingw32-binutils.spec
+++ b/mingw32-binutils.spec
@@ -64,10 +64,10 @@ rm -rf $RPM_BUILD_ROOT
%files
-%defattr(-,root,root)
+%defattr(-,root,root,-)
%{_mandir}/man1/*
%{_bindir}/i686-pc-mingw32-*
-%{_prefix}/i686-pc-mingw32/bin
+%{_prefix}/i686-pc-mingw32/bin/*
%{_prefix}/i686-pc-mingw32/lib/ldscripts
@@ -76,6 +76,7 @@ rm -rf $RPM_BUILD_ROOT
- Update to 2.21
- Added a patch to use runtime pseudo reloc v1 by default as the version of
mingw32-runtime we have does not support v2.
+- Don't own the /usr/i686-pc-mingw32/bin/ directory
* Tue Feb 08 2011 Fedora Release Engineering <rel-eng(a)lists.fedoraproject.org> - 2.20.51.0.10-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_15_Mass_Rebuild
13 years, 1 month
[mingw32-binutils] Use runtime pseudo reloc v1 by default
by Kalev Lember
commit e8523ce48fe8d922650ebb6818ec3dfc455dbc64
Author: Kalev Lember <kalev(a)smartlink.ee>
Date: Thu Mar 17 14:59:15 2011 +0200
Use runtime pseudo reloc v1 by default
The version of mingw32-runtime we have does not support v2.
mingw32-binutils-2.21-pseudo_reloc_v1.patch | 12 ++++++++++++
mingw32-binutils.spec | 4 ++++
2 files changed, 16 insertions(+), 0 deletions(-)
---
diff --git a/mingw32-binutils-2.21-pseudo_reloc_v1.patch b/mingw32-binutils-2.21-pseudo_reloc_v1.patch
new file mode 100644
index 0000000..116d9c7
--- /dev/null
+++ b/mingw32-binutils-2.21-pseudo_reloc_v1.patch
@@ -0,0 +1,12 @@
+diff -up binutils-2.21/ld/emultempl/pe.em.pseudo_reloc_v1 binutils-2.21/ld/emultempl/pe.em
+--- binutils-2.21/ld/emultempl/pe.em.pseudo_reloc_v1 2010-09-22 11:03:41.000000000 +0300
++++ binutils-2.21/ld/emultempl/pe.em 2011-03-17 13:53:13.000000000 +0200
+@@ -100,7 +100,7 @@ fragment <<EOF
+ #endif
+
+ #if defined(TARGET_IS_i386pe)
+-#define DEFAULT_PSEUDO_RELOC_VERSION 2
++#define DEFAULT_PSEUDO_RELOC_VERSION 1
+ #else
+ #define DEFAULT_PSEUDO_RELOC_VERSION 1
+ #endif
diff --git a/mingw32-binutils.spec b/mingw32-binutils.spec
index bba5ed9..80a49bd 100644
--- a/mingw32-binutils.spec
+++ b/mingw32-binutils.spec
@@ -7,6 +7,7 @@ License: GPLv2+ and LGPLv2+ and GPLv3+ and LGPLv3+
Group: Development/Libraries
URL: http://www.gnu.org/software/binutils/
Source0: http://ftp.gnu.org/gnu/binutils/binutils-%{version}.tar.bz2
+Patch0: mingw32-binutils-2.21-pseudo_reloc_v1.patch
BuildRoot: %{_tmppath}/%{name}-%{version}-%{release}-root-%(%{__id_u} -n)
BuildRequires: flex
@@ -25,6 +26,7 @@ understand Windows executables and DLLs.
%prep
%setup -q -n binutils-%{version}
+%patch0 -p1 -b .pseudo_reloc_v1
%build
@@ -72,6 +74,8 @@ rm -rf $RPM_BUILD_ROOT
%changelog
* Thu Mar 17 2011 Kalev Lember <kalev(a)smartlink.ee> - 2.21-1
- Update to 2.21
+- Added a patch to use runtime pseudo reloc v1 by default as the version of
+ mingw32-runtime we have does not support v2.
* Tue Feb 08 2011 Fedora Release Engineering <rel-eng(a)lists.fedoraproject.org> - 2.20.51.0.10-2
- Rebuilt for https://fedoraproject.org/wiki/Fedora_15_Mass_Rebuild
13 years, 1 month
