Re: [gtk-list] Re: More IRIX problems

[Drazen Kacar <dave srce hr>]

Erik Mouw wrote:
> >         gcc -Wall -g first.c -o first `gtk-config --cflags` `gtk-config
> > --libs`
> > ld32: WARNING 85: definition of __register_frame_info_table in
> > /usr/local/lib/libgtk.so preempts that definition in
> > /usr/local/lib/libgdk.so.
> > ld32: WARNING 85: definition of __frame_state_for in
> > /usr/local/lib/libgtk.so preempts that definition in
> > /usr/local/lib/libgdk.so.
> 
> That warning about __register_frame_info_table sounds familiar, I also get

Welcome to the wonderfull world of gcc. I've just experienced a similar
problem on Solaris. I have gcc and Sun's cc installed, and one of my
co-workers was compiling lynx with slang support. His version of slang
was compiled with gcc. He also compiled lynx with gcc and everything worked
fine. Then we moved binary to my host which has the same version
of slang compiled with Sun's cc. Lynx didn't work, because the dynamic
linker couldn't find those __register symbols.

Then we deleted lynx binary in his build tree, tar'ed it all and copied
to my host. make. Lynx builds. It works. Copy binary to his host with
gcc slang. It works. gcc sucks.

The problem is that each compiler has its own init routines which get
linked into executable. They are not the same and they need not be the same.
But gcc links them into shared libraries, which means that those routines
won't be linked into executable if they are already present in the shared
library. And the executable won't work if you give it the same version of
shared library which was built with a different compiler. Sounds like C++?
If you have those warnings, your libraries are infected.

I consider this a severe bug, either in gcc or in our instalation, but I
don't maintain our gcc and I wasn't checking further. Linux people don't
experience this situation, since gcc is the only compiler available,
but if you build programs on other platforms with gcc, you'll get what
you asked for eventually.

BTW, that __register_something thing is probably a function which
just loads a number in one register and then jumps elsewhere.

>   Symbols from /usr/lib32/libc.so:
> 
>   [Index]   Value      Size    Type  Bind  Other     Shndx   Name
> 
>   [333]   | 262456880|     436|FUNC |WEAK |DEFAULT  |MIPS_TEXT|_getpwuid
>   [334]   | 262456880|     436|FUNC |WEAK |DEFAULT  |MIPS_TEXT|getpwuid
>   [398]   | 262523440|      12|FUNC |GLOB |DEFAULT  |MIPS_TEXT|__sgi_getpwuid_r
>   [399]   | 262523440|      12|FUNC |WEAK |DEFAULT  |MIPS_TEXT|getpwuid_r
>   [2264]  | 262513856|     568|FUNC |GLOB |HIDDEN   |MIPS_TEXT|__files_getpwuid
>   [2404]  | 262456880|     436|FUNC |GLOB |DEFAULT  |MIPS_TEXT|__sgi_getpwuid
> 
> But IMHO the size is actually a bit small, unless it calls getpwuid().
> What's the getpwuid_r() function supposed to do? I don't have a manpage
> for it.

If it's declared as a WEAK symbol, then it's just a pointer to another
function. getpwuid_r() is a thread safe version of getpwuid().

-- 
 .-.   .-.    Life is a sexually transmitted disease.
(_  \ /  _)
     |        dave@srce.hr
     |        dave@fly.cc.fer.hr