public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
* using assert (__eprintf) in shared libraries
@ 1999-12-25 10:51 R. Bernstein
  1999-12-31 22:24 ` R. Bernstein
  0 siblings, 1 reply; 2+ messages in thread
From: R. Bernstein @ 1999-12-25 10:51 UTC (permalink / raw)
  To: help-gcc

A number of packages, like MesaGL and audiofile want to build 
with shared libraries and at run time I often 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.

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? 

Any thoughts? 

^ permalink raw reply	[flat|nested] 2+ messages in thread

* using assert (__eprintf) in shared libraries
  1999-12-25 10:51 using assert (__eprintf) in shared libraries R. Bernstein
@ 1999-12-31 22:24 ` R. Bernstein
  0 siblings, 0 replies; 2+ messages in thread
From: R. Bernstein @ 1999-12-31 22:24 UTC (permalink / raw)
  To: help-gcc

A number of packages, like MesaGL and audiofile want to build 
with shared libraries and at run time I often 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.

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? 

Any thoughts? 

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~1999-12-31 22:24 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1999-12-25 10:51 using assert (__eprintf) in shared libraries R. Bernstein
1999-12-31 22:24 ` R. Bernstein

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).