Re: using assert (__eprintf) in shared libraries

[Geoff Keating <geoffk at envy dot cygnus dot com>]

"R. Bernstein" <rocky@panix.com> writes:

> A number of packages, like MesaGL and audiofile want to build 
> with shared libraries and at run time I get a message like
> 
> ld.so.1: xmms: fatal: relocation error: file /opt/platform/X11/lib/libGL.so: symbol __eprintf: referenced symbol not found
> 
> Note the error is pretty far from the source of the problem: xmms uses
> libGL and that uses gcc's __eprintf.
> 
> What is going on is that the source code to say libGL.so uses assert(), and 
> under gcc this uses in __eprintf from libgcc.a. 
> 
> I've been able to fix such problems by extracting _eprintf.o from libgcc.a 
> and linking this in explicitly into the shared objects.

I don't understand how __eprintf was not linked into these shared
objects in the first place.

If you specify

gcc -shared <lots of objects> -o foo.so

then GCC will add -lgcc -lc -lgcc to the link line, which will ensure
that any libgcc.a routines are properly added into the shared object.

It may be that these programs are using 'ld' to link the shared
objects, which is wrong if the .o files are being built with GCC; they
should use the appropriate driver, 'gcc', 'g++', or whatever.

> But I'm not sure where the real problem lies -- should there be a shared
> libgcc? Are the builds for such programs at fault? 
> And what the best way to fix? 

A shared libgcc would not fix this problem completely, because the
application might be compiled with some other compiler.

-- 
- Geoffrey Keating <geoffk@cygnus.com>