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=628199

Felipe Contreras felipe.contreras@gmail.com changed:

What |Removed |Added ---------------------------------------------------------------------------- Summary|mingw32: libintl-8.dll |mingw32: libintl-8.dll |instead of libintl.dll |instead of intl.dll

--- Comment #1 from Felipe Contreras felipe.contreras@gmail.com 2010-08-28 11:20:49 EDT --- Er, intl.dll

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=628199

--- Comment #3 from Felipe Contreras felipe.contreras@gmail.com 2010-09-03 06:23:32 EDT --- (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.

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=628199

Felipe Contreras felipe.contreras@gmail.com changed:

What |Removed |Added ---------------------------------------------------------------------------- Flag|needinfo?(felipe.contreras@ | |gmail.com) |

--- Comment #5 from Felipe Contreras felipe.contreras@gmail.com 2010-11-10 13:16:11 EST --- (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.

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=628199

--- Comment #7 from Felipe Contreras felipe.contreras@gmail.com 2010-11-10 14:54:17 EST --- Ok, bug fixed I guess.