After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 77358 - Check for iconv workingness at configure or 'make install' time.
Check for iconv workingness at configure or 'make install' time.
Status: RESOLVED FIXED
Product: glib
Classification: Platform
Component: general
2.0.x
Other Solaris
: Normal normal
: ---
Assigned To: gtkdev
gtkdev
: 81818 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2002-04-02 12:31 UTC by nirkko
Modified: 2011-02-18 16:14 UTC
See Also:
GNOME target: ---
GNOME version: 2.0



Description nirkko 2002-04-02 12:31:21 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.
Comment 1 nirkko 2002-04-02 18:09:54 UTC
see pango bug # 77341
Comment 2 nirkko 2002-04-05 08:57:48 UTC
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?  ;-)
Comment 3 Colin Leroy 2002-04-05 19:58:59 UTC
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.
Comment 4 Colin Leroy 2002-04-05 20:19:02 UTC
Hello again,
No segfault anymore with libiconv 1.7 installed and used
(--with-libiconv=gnu).
Comment 5 nirkko 2002-04-05 20:33:08 UTC
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).

Comment 6 nirkko 2002-04-08 08:41:14 UTC
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.

Comment 7 Owen Taylor 2002-05-13 21:52:58 UTC
 - 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.  
Comment 8 Owen Taylor 2002-06-13 15:25:30 UTC
*** Bug 81818 has been marked as a duplicate of this bug. ***
Comment 9 Owen Taylor 2002-06-13 15:25:35 UTC
*** Bug 81818 has been marked as a duplicate of this bug. ***
Comment 10 nirkko 2002-06-13 17:01:47 UTC
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?
Comment 11 Owen Taylor 2002-06-13 23:20:10 UTC
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.
Comment 12 Kjartan Maraas 2005-01-05 13:08:25 UTC
No comment in a couple of years. Can we close this now?
Comment 13 nirkko 2005-01-05 17:57:46 UTC
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.]
Comment 14 Kjartan Maraas 2005-01-06 09:26:28 UTC
Ok, going out on a limb and closing this then. Owen, you can spank me if I'm out
of line here :-)