Re: gucharmap makes qtk-query-immodules segfault



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]