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

[Erik Mouw <J A K Mouw its tudelft nl>]

On Fri, 05 Feb 1999 14:35:24 +0100, gtk-list@redhat.com (Drazen Kacar) wrote:
> 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.

Shared libraries are a different story. There are many ways to create a
shared library in the wrong way. If you use libtool for creating shared
libraries, you should get libraries that can be used with both the
system's native C compiler as well as the gcc compiler.

> 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.

You haven't seen the SGI MipsPRO C compiler. That sucks for many more
Lovelace, IMHO. The error messages can be very cryptic, so you you don't
even get a clue what's wrong in your program. On the other hand, it does
quite a nice job on optimization.

> 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.

I actually maintain gcc at my site, so I'm sure that I did not change the
compiler. THe funny thing about my problem is that I get the messages with
_exactly_ the same compiler configuration.

If you want to see your Slowaris problems on Linux, install gcc 2.7.2
together with egcs 1.0. ;-)

>> 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. 

On IRIX, if a symbol is declared weak, it means that it is safe to preempt
it with another implementation. Almost all symbols in the C library are
weak, so you can use your own implementation for each of them. A lot of
malloc()/free() debuggers actually use this feature.

> getpwuid_r() is a thread safe version of getpwuid().

So getpwuid_r() probably sets a lock and calls getpwuid(). That would
explain why it is so small.



Erik

-- 
J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department
of Electrical Engineering, Faculty of Information Technology and Systems,
Delft University of Technology, PO BOX 5031,  2600 GA Delft, The Netherlands
Phone: +31-15-2785859  Fax: +31-15-2781843  Email J.A.K.Mouw@its.tudelft.nl
WWW: http://www-ict.its.tudelft.nl/~erik/