Re: Proposal: drop the hard dependency on mingw32-gettext from mingw32-glib2
On 10/12/2010 01:58 PM, Erik van Pienbroek wrote:
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.
<snip>
I was browsing GTK+ win32 builds web page today and it would appear that
they have reverted back to _not using_ libproxy-intl. The reason why
they switched back to directly linking libintl isn't apparent from the
web page, all it says is:
"Previously the "proxy-libintl" library that loads the gettext-runtime
DLL dynamically was used, but now the GTK+ stack is just linked normally
to intl.dll."
"libproxy-intl" has been in Fedora for several months now. I am not sure
I like it very much; several packages that use gettext now need patching
and the patches aren't often upstreamable and need rebasing every time
we update to new upstream sources.
If it was only libraries it might be OK, but I'm afraid it will turn off
people if their programs don't build without patching.
One of the problems I ran into today was caused by "libproxy-intl". It
turned out that linking to static libintl.a has a side effect which
causes gettext functions being exported in libgnutls-26.dll. It wouldn't
be much of a problem on itself, but we have other binaries
(mingw32-webkitgtk) that now try to resolve gettext symbols from
libgnutls-26.dll. When I built a different version of gnutls locally
which didn't export gettext symbols, it broke mingw32-webkitgtk binary.
I'm am not sure it pays off diverging from upstream gettext like that.
--
Kalev