GNOME Bugzilla – Bug 77358
Check for iconv workingness at configure or 'make install' time.
Last modified: 2011-02-18 16:14:20 UTC
glib-2.0.1 makes pango build/install fail with segfault in pango-querymodules: both pango-1.0.0 and pango-1.0.1 are affected. with former glib-2.0.0, pango-1.0.0 works fine. compiler used: gcc-3.0.4; default options (CFLAGS not set -> -g -O2) build commands used (for all versions tried): ./configure --enable-static --enable-shared --enable-debug=no glib-2.0.1 build and installs, but pango build fails because pango-querymodules segfaults if glib-2.0.1 is installed, but not when the old glib-2.0.0 is re-installed.
see pango bug # 77341
after installation of GNU libiconv-1.7 and configuring and installing glib-1.0.1 with libiconv, pango-1.0.1 builds alright, and 'make check' passes. 'make check' in glib-2.0.1 still fails and segfaults on some tests, though. But this was already in 2.0.0 Still, should it not work also with native iconv, especially since it worked for 1.0.0? (and by the way, why does 1.0.1 install in a directory called 1.0.0? ;-)
Hello, I got that too. I'll try to install libiconv. To be more precise, the problem appears (gdb pango-querymodule) at a g_printf() call. And to be more precise, the problem is in g_printf() itself, line 833 of gmessage.c, due to strdup_convert (string, charset) returning NULL if I correctly understood the tests I did.
Hello again, No segfault anymore with libiconv 1.7 installed and used (--with-libiconv=gnu).
also, both the gtk+-2.0.0 and gtk+-2.0.1demo program 'gtk-demo' crashes with glib-2.0.1_native-iconv, but runs fine with glib-2.0.1_libiconv. (as opposed to the pango-querymodules crash, however, gtk-demo doesn't work with glib-2.0.0_native-iconv, but pango-querymodules does).
received additional info from Thomas Klausner - wiz@danbala.tuwien.ac.at appending this here for him because he can't: Hi! I recently encountered the same problem when compiling pango on NetBSD-1.5ZC, with XFree86-4.1.0 installed. The proposed workaround with --with-libiconv=gnu does not work for me. The problem does not appear on a similar machine which has XFree86-3.3.6 installed. The problem seems to be that g_get_charset in g_print (in gmessages.c in glib-2.0.1) returns "646" as charset, and strdup_convert fails to convert the string "/home/wiz/cvs/pkgsrc/devel/pango/work/pango-1.0.1/modules/./arabic/pango-arabic-x.la ArabicScriptEngineX PangoEngineShape PangoRenderX " with "646" as argument and just returns a NULL pointer, which g_print does not check. I don't know how to append this information to the bug report, so it's CC'd to the three email addresses found there. Bye, Thomas -- Thomas Klausner - wiz@danbala.tuwien.ac.at When all other means of communication fail, try words.
- The segfault for the conversion failing has been fixed (bug 78197) - The netbsd segfault problem is that libiconv's charset.alias didn't include some netbsd fixes in the GLib charset.alias. This has now been fixed in the netbsd libiconv port and upstream. So, the remaining problem seems to be that the output of g_get_charset() for the "C" loclae on older Solaris using native iconv() isn't understood by g_convert() / g_iconv_open(). Not tracked down yet.
*** Bug 81818 has been marked as a duplicate of this bug. ***
responding here to "-- Additional Comments From Owen Taylor 2002-06-13 11:25 --" concerning bug id 81818, which is a duplicate of this here: > 1) In the situation that you are in, GLib should have failed > to configure with an error message telling you to > install SUNWuiu8 or GNU libiconv. In an ideal world. > > Unfortunately, this is really hard to do, because > ... even if it wasn't hard to do this would still not seem ideal to me: for binary distributions, or people like me who build the package on one machine and install it on several others, the build machine might have the extra packages installed, but not the other machines. Therefore, I think a clear error message at runtime is essential, even if a built-in fall-back converter is needed to make it possible to output the error message. Otherwise, what's wrong with a no-conversion message like fprintf(stderr, "us-english-only error message"); as a fallback?
The runtime error is no longer a segfault, it now tells you that it can't convert the message and the character sets it was trying to convert betweeen doing more than that would seem strange to me.
No comment in a couple of years. Can we close this now?
Considering Comment #11, I thought it was already closed at that time... [Strictly speaking, I don't know because since then, I was always using GNU libiconv (currently 1.9.2) for later builds (seems to be needed pretty much by anything, including gcc itself, etc...) so now I don't know what would happen without.]
Ok, going out on a limb and closing this then. Owen, you can spank me if I'm out of line here :-)