Bug 628199

Summary:	mingw32: libintl-8.dll instead of intl.dll
Product:	[Fedora] Fedora	Reporter:	Felipe Contreras <felipe.contreras>
Component:	mingw32-gettext	Assignee:	Richard W.M. Jones <rjones>
Status:	CLOSED RAWHIDE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	medium	Docs Contact:
Priority:	low
Version:	13	CC:	erik-fedora, fedora-mingw, lfarkas, rjones
Target Milestone:	---
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2010-11-10 19:57:03 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Felipe Contreras 2010-08-28 15:14:07 UTC

Most GTK+ distributions in win32 use libintl.dll, so libraries compiled in Fedora don't work there.

Comment 1 Felipe Contreras 2010-08-28 15:20:49 UTC

Er, intl.dll

Comment 2 Richard W.M. Jones 2010-09-03 07:30:28 UTC

You're supposed to use our gtk libraries, packaged using (eg)
nsiswrapper.  Mixing our compiled binary with some other
gtk libraries you found could cause all sorts of subtle problems.

Comment 3 Felipe Contreras 2010-09-03 10:23:32 UTC

(In reply to comment #2)
> You're supposed to use our gtk libraries, packaged using (eg)
> nsiswrapper.  Mixing our compiled binary with some other
> gtk libraries you found could cause all sorts of subtle problems.

That's so not what I'm supposed to do.

I'm writing a simple Pidgin plugin; it's a single dll that is supposed to link against libpurple, and glib, and so on. Since all these libraries preserve backwards compatibility there's no risk of linking against older ones. So I link against mingw32 ones, and they work fine.

Nobody would expect my plugin to distribute it's own libpurple, and glib.

In fact, the whole purpose of mingw32 is to not distribute it's own libc and win32 libraries, but to link to the ones already present on the system.

Comment 4 Erik van Pienbroek 2010-11-10 16:37:43 UTC

The mingw32-gettext package in rawhide has been updated so that it uses a small wrapper library called proxy-libintl. This means that packages which link against libintl don't need to have libintl-8.dll installed in order to run. If the libintl-8.dll file is missing then no translations will be used. In addition to this binaries which have been rebuilt to use proxy-libintl (no source code modifications required) can also use intl.dll instead of libintl-8.dll if it's available.

Does this solve this issue for you?

Comment 5 Felipe Contreras 2010-11-10 18:16:11 UTC

(In reply to comment #4)
> The mingw32-gettext package in rawhide has been updated so that it uses a small
> wrapper library called proxy-libintl. This means that packages which link
> against libintl don't need to have libintl-8.dll installed in order to run. If
> the libintl-8.dll file is missing then no translations will be used. In
> addition to this binaries which have been rebuilt to use proxy-libintl (no
> source code modifications required) can also use intl.dll instead of
> libintl-8.dll if it's available.
> 
> Does this solve this issue for you?

So, if I build on Fedora, the binary would not link directly to libintl-8.dll, and at run-time it would detect libintl.dll, and use that instead?

If so, yes, that fixes the issue for me.

Comment 6 Erik van Pienbroek 2010-11-10 18:28:30 UTC

Yes that is the case with the mingw32-gettext package in rawhide

Comment 7 Felipe Contreras 2010-11-10 19:54:17 UTC

Ok, bug fixed I guess.