GNOME Bugzilla – Bug 81818
during build, gdk-pixbuf-csource fails on several stock pixmaps
Last modified: 2010-07-10 04:06:46 UTC
On Solaris 5.6, gcc 2.95.2, using the libpng, libjpeg, and libtiff from the GTK FTP site, and zlib 1.1.4: When running gdk-pixbuf-csource on 5 of the png files in gtk/stock-icons, ../../gdk-pixbuf/gdk-pixbuf-csource --raw --build-list $name ${name}.png > ${name}.h they fail with an error display: (process:9205): GLib-CRITICAL (recursed) **: file gstring.c: line 423 (g_string_append): assertion `val != NULL' failed aborting... The bad 5 files are: stock_apply_20.png stock_cancel_20.png stock_close_20.png stock_close_24.png stock_ok_20.png
Hard to tell here .. the error message should be better better with GLib-2.0.3 (will be out soon) ... something like: GLib: Cannot convert message: cannot open converter from <A> to <B> [ the message that it was actually trying to produce, as raw UTF-8 ] But I can't really guess either why it cannot do the conversion or what the original error message was at this point.
Please reopen if you add more information.
I figured out (with gdb) at least why it can't do the conversion. There's a status message being reported by gdk-pixbuf-csource while doing the conversion of the stock images. But the system deduces that the charset on my Solaris 5.6 machine is ASCII (seen with gdb), and it has no converter installed for ASCII->UTF8 conversion. So it produces the message about the converter, and bombs out. I'd strongly suggest that you add to GLib the capability to convert from ASCII to UTF8 -- it's pretty much a noop. Bill
The UTF-8 => ASCII problem is bug 77358; thinking about it some it might be, as mentioned in the GLib INSTALL file: If you are using the native iconv implementation on Solaris instead of libiconv, you'll need to make sure that you have the converters between locale encodings and UTF-8 installed. At a minimum you'll need the SUNWuiu8 package. You probably should also install the SUNWciu8, SUNWhiu8, SUNWjiu8, and SUNWkiu8 packages. Yes, UTF-8 => ASCII is easy to code .. but that's not really the point; GLib requires an 'iconv()' functionality ... if the system doesn't have one, then you can install it with libiconv and configure --with-libiconv; Solaris has iconv, but it's pretty limited by default, especially if you are missing the optional packages. BTW - what's the status message? I don't see anything in gdk-pixbuf-csource that should print anything out, and I don't get any mesages.
1) I still think ASCII->UTF8 should be specially handled, because it's the default charset you use when you can't figure out what the native charset is. Under those conditions, I'd also expect no converter to be installed. Either use UTF8 as the fallback, or add a special converter, would be my take on it. 2) Here's a stack trace. Note that this only occurs on the five images I noted. This GDB was configured as "sparc-sun-solaris2.6"... (gdb) run --raw --build-list stock_apply_20 ./stock_apply_20.png Starting program: /var/tmp/gtk-2.0.1/src/gtk/gtk+-2.0.2/gtk/stock-icons/../../gdk-pixbuf/.libs/gdk-pixbuf-csource --raw --build-list stock_apply_20 ./stock_apply_20.png (process:9205): GLib-CRITICAL (recursed) **: file gstring.c: line 423 (g_string_append): assertion `val != NULL' failed aborting... Program received signal SIGABRT, Aborted. 0xef58828c in _libc_kill () from /usr/lib/libc.so.1 (gdb) bt
+ Trace 23746
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 iconv encoding names aren't standardized; we have a bunch of code and config files to deal with this, but that isn't available to configure. I suppose we could do some hack like making the check for functional 'iconv' at 'make' time. Probably the right thing to do, as opposed to people finding the problem with weird failures in GTK+. 2) Ah, I see the reason why you were getting those warning messages from gdk-pixbuf-csource ... some of the images have comments, and you are also missing the conversion from ISO-8859-1 => UTF-8. *** This bug has been marked as a duplicate of 77358 ***
Sure, makes sense. You may remember that I tend to prefer hard-edged solutions to these problems, too. But perhaps, rather than default to ASCII if the code can't figure out the default charset, you could just abort? If you can't figure out the charset, probably nothing much else will work, either.