Packaging error, thanks for the report. As such not a problem in the GLib source code, but in the script that was used to build one particular distribution of GLib for Windows. (But luckily the packager, i.e. I, happen to get glib bugzilla mail, too.)

thanks Tor. unrelated to the report, but any chance for a gdk-pixbuf windows release?

Ah, thanks for reminding me. Of course. gdk-pixbuf 2.22.0 is now being synced there.

thanks. where will i have to look? /dependencies/gdk-pixbuf*.zip ?

Nah, gdk-pixbuf is part of the same GTK+ stack, so just one level up from "gtk+"

thank you :)

Tor, i'm not sure where i should report this, but it may be just another packaging error.

now i'm compiling against glib 2.26 and gtk+ 2.22. i copied intl.dll (from gettext-runtime_0.18.1.1-2_win32.zip) to the application folder as usually, but it complained that libintl.dll is not found. i thought that is has finally been renamed like for win64 (although for win64 it's libintl-8.dll). so i renamed intl.dll to libintl.dll. then it told me it can't find intl.dll.

if i copy the *exact same* intl.dll as both intl.dll and libintl.dll, it works fine.

and btw, there's also an incoherency for freetpye, that is, it's freetype6.dll for win32 and libfreetype-6.dll for win64.

Hmm, odd. Can you find out exactly what it is that depends on a libintl.dll? It might be some 3rd-party gdk-pixbuf loader or theme engine you are using, for instance. I don't think I have ever seen a libintl DLL that would be called libintl.dll. What I've seen is either the traditional name intl.dll, or the one you get if you build it using libtoool, libintl-8.dll.

Also for freetype the name of the DLL as as it is for backward compatibility... the previously used gnuwin32 build of it used to be called so freetype6.dll, and as far as I know the current version is still API and ABI compatible, so the name can (and should, IMHO) be the same. But yeah, perhaps mostly a matter of taste...

there's no 3rd party gtk stuff AFAIK. here's my previous toolchain for win32 and win64 respectively:

http://code.google.com/p/xchat-wdk/source/browse/build/deps-x86.txt?r=98c8976aa381d5e79411cd9e8bf0221aa60f7db6

http://code.google.com/p/xchat-wdk/source/browse/build/deps-x64.txt?r=08586f35404ccc7451a5e2feda250f7753a4532e

i've upgraded gettext-runtime, gettext-runtime-dev, gettext-tools, glib, glib-dev, gtk+ and gtk+-dev (to their latest version) so far, and added gdk-pixbuf. but only for x86 as there are no x64 packages yet.

i'm linking against intl.lib since xchat-wdk provides translations. it links fine, i copy intl.dll, and then it wants libintl.dll.

if that matters, for gettext 0.17 it can't find the entry point for libintl_setlocale in *intl.dll* (even if i copy intl.dll to libintl.dll), that's why i upgraded to 0.18.

eh, even stranger: if i compile and link against 0.17, then copy the 0.18 intl.dll to the app folder, then it works fine without the libintl.dll copy. it must be some dll name exporting problem i guess. now i'll try to track down which file causes this...

Ah, ok. The intl.lib import library indeed seems to refer to a "libintl.dll". I create it from the libintl.def using just:

lib.exe -machine:x86 -def:libintl.def -out:intl.lib

I clearly have forgotten to add a -name: switch to indicate the DLL name, so lib apparently then uses as default the basename of the .def file with .dll appended. I probably won't bother rebuilding gettext just because of this, though, hmm. Maybe I will just pull a fast one and replace the intl.lib in the existing package files...

heh, i was just about to post my findings :) yeah, that overwriting thing should be good. many thanks.

btw, Tor, i'd like to point it out that gettext-tools 0.18 is effectively empty for both win32 and win64, so i need to use the win32 0.17 zip for msgfmt ATM.

The gettext-tools-dev_0.18.1.1-2_win*.zip files aren't empty, the non-dev gettext-tools ones are... That's on purpose, because "tools" by definition are for developers, and I just need to have both foo and foo-dev packages because some of my scripts assume that... Yeah, it's a bit silly.

well, i'm talking about 

http://ftp.gnome.org/pub/gnome/binaries/win32/dependencies/gettext-tools-0.17.zip

vs.

http://ftp.gnome.org/pub/gnome/binaries/win32/dependencies/gettext-tools_0.18.1.1-2_win32.zip

or

http://ftp.gnome.org/pub/gnome/binaries/win64/dependencies/gettext-tools_0.18.1.1-1_win64.zip

the first one contains all the tools such as msgfmt (4,9M in size) while the latter two only contains a manifest file.

...and they're supposed to be the same package (at least they have the same name) just in different versions.

Yeah, well, how I package stuff is just a policy I make up and change now and then, so occasionally consistency is broken, yes.

oh sorry, i see some files have been moved from -tools to -runtime-dev, such as envsubst.exe, gettext.exe and ngettext.exe.

but there are a lot of msg*.exe files missing in the 0.18 series, are they now in a separate package?

i know this is not the proper place to ask (there isn't any), but are the windows builds of glib 2.26.1 and gtk 2.22.1 expected to be available sometime?