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 _______________________________________________ gtk-list mailing list gtk-list@xxxxxxxxx http://mail.gnome.org/mailman/listinfo/gtk-list
