Re: Gtk2 Win32 setup problem ...

[Tor Lillqvist <tml iki fi>]

Kuang-Chun Cheng writes on gtk-list:
 > I can't find any document related to Pango's setup and the format of
 > pango.aliases ... could someone tell me where can I find such document ?

Read the source code?

 > Gtk-WARNING **: Error loading theme icon for stock:
 > Failed to open file '': No such file or directory
 > GLib-GObject-CRITICAL **: g_object_unref: assertion `G_IS_OBJECT(object)' failed
 > 
 > and the application crash.

Is this with trunk GTK+? There has been changes related to the stock
icon code in trunk, and I get some warnings about some icons, too, in
trunk when running gtk-demo's stock item browser.. The stock icon
stuff is a bit of a mystery to me, and I really don't understand how
it works.

 > Well, the same examples run smoothly under native Linux, so I
 > expect that it's my setup problem under Win32.  Again, I can't find
 > enough information describe Gtk2's setup.  Where is Gtk2's stock
 > icon ?

Again, I fear the best (only?) description of how this is supposed to
work is the source code...

 > I build all the packages from libiconv, gettext, glib ... gtk2
 > under Linux from scratch instead of using pre-build binaries which
 > could be found on Tor Lillqvist's web site.

This message is much better suited for the gtk-devel-list list. If you
read that, you will notice that Alberto Ruiz also is right now also
working on the same thing (cross-building GTK+ and everything it
depends on). Please join that list and follow up there.

Did you manage to get libintl (gettext-runtime) actually working?
Alberto Ruiz had probems with that.

The situation with GNU libintl on Windows is a bit of a mess. I
distribute gettext-runtime 0.14.5 binaries compiled with MSVC (because
MSVC used to be the officially endorsed way to build gettext on
Windows), and they work. The name for the libintl (gettext-runtime)
DLL in such a build is intl.dll.

Now, in the current gettext sources support for MSVC has been
dropped. One is supposed to use the autofoo mechanism (and de facto
thus gcc) also on Windows. (No problem with that as such, gcc is what
I use for everything else, but read on.) 

That means that without additional (minor?) hackery, libtool will
produce a DLL called libintl-0.dll or something like that. That is a
problem, because the libintl API and ABI has not changed incompatibly
as far as I know. Unless one wants to force all dependees to be
relinked one should produce a DLL with the same DLL name as earlier,
intl.dll, also when building a current gettext-runtime.

And then there is the mystery how autofoo decides where to install the
message catalogs (mo files). For some reason, for me the autofoo in
glib, gtk+ etc has always decided that they belong under
"lib/locale/*", as if the mo format was platform dependent. On Linux,
the same GNU gettext message catalogs are installed under
"share/locale/*", indicating they are platform independent. What goes
on? This is a mess that should be thoroughly investigated.

The same situation as for libintl also holds for libiconv, BTW.

It would be somewhat unfortunate if people start distributing builds
of GTK+, for instance, that use the same name for the GTK+ DLLs, but
still require differently named libintl or libiconv DLLs.

--tml