Re: gucharmap makes qtk-query-immodules segfault
- From: Alexander Larsson <alexl redhat com>
- To: Frank Boehme <f boehme cs ucc ie>
- Cc: Noah Levitt <nlevitt columbia edu>, gtk dev list <gtk-devel-list gnome org>
- Subject: Re: gucharmap makes qtk-query-immodules segfault
- Date: 21 Aug 2003 11:42:03 +0200
On Wed, 2003-08-20 at 17:44, Frank Boehme wrote:
> Noah Levitt wrote:
> >
> > Well, the CFLAGS I normally use are "-Wall -pipe -g -O2",
> > but I wouldn't expect that to be important, though Im not
> > sure.
>
> Well, yesterday I did a lot of recompiles and gdb sessions and now I am
> positive that with gcc 3.3, the switch -O3 (or -On wuth n > 2) will
> miscompile *any* gtk input module, including gucharmap.so. So mu problem
> is not specific to gucharmap at all. At least that is my situation.
>
> I suppose this must be known but I can hardly check sicnce
> http://bugzilla.gnome.org/query.cgi is very slow from here (and not
> exactly straightforward to use for the non-developers).
>
> First, a sum up of my findings:
>
> Whenever any input module is compiled with -O3 present, then the problem
> arises. -O3 has no bad influence on the functionality of the rest of
> GTK, including gtk-query-immodules-2.0.
>
> The bug causes query-immodules-2.0 receiving SIGSEGV as soon as it
> parses any immodule which had been compiled with -O3. Again, it does not
> matter how gtk-query-immodules-2.0 itself was compiled. It does also not
> matter whether or not a module was given as command line argument.
I have some issues with gucharmap and query-modules too. I'm trying to
build it on x864-64 for redhat.
What happens to me is this:
/usr/bin/gtk-query-immodules-2.0 .libs/im-gucharmap.so
# GTK+ Input Method Modules file
# Automatically generated file, do not edit
#
Cannot load module /usr/src/redhat/BUILD/gnome-utils-2.3.4/gucharmap-0.8.0/gucharmap/.libs/im-gucharmap.so: /usr/lib64/librt.so.1: symbol __librt_disable_asynccancel, version GLIBC_PRIVATE not defined in file libc.so.6 with link time reference
/usr/src/redhat/BUILD/gnome-utils-2.3.4/gucharmap-0.8.0/gucharmap/.libs/im-gucharmap.so does not export GTK+ IM module API: /usr/lib64/librt.so.1: symbol __librt_disable_asynccancel, version GLIBC_PRIVATE not defined in file libc.so.6 with link time reference
Basically, it claims librt is looking for a symbol
(__librt_disable_asynccancel) that it believes is in libc.so, but can't
find it there. The reason for this is that it somehow mixes up the TLS
versions of libc and librt. gtk-query-immodules-2.0 does not link to
librt, only to libc. Since the system supports TLS it loads
/usr/lib64/tls/libc.so for libc. But then when loading im-gucharmap.so
it notices that libgnomevfs needs librt.so. For some reason it then
picks the non-TLS version of this one. This is a mismatch that is very
bad.
In my case the __librt_disable_asynccancel is hidden in the TLS versions
but not in the non-TLS versions, so linking just fails. If linking would
succees I would expect it to break in other mysterious ways though, like
your mysterious segfault.
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Alexander Larsson Red Hat, Inc
alexl redhat com alla lysator liu se
He's a suave Catholic grifter with no name. She's a sarcastic bisexual barmaid
in the witness protection program. They fight crime!
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]