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.