Re: binaries compiled on slink don't run anywhere else
>>>>> On Mon, 16 Nov 1998 08:12:05 -0600, "Marcelo E. Magallon" <mmagallo@efis.ucr.ac.cr> said:
Marcelo> On Sun, Nov 15, 1998 at 11:30:31PM -0500, James LewisMoss
Marcelo> wrote:
>> Actually it seems to live in some of the egcs objects and libs:
Marcelo> That's where I'm confused.
Marcelo> $ nm 1000s-O2 | grep register_frame_info
Marcelo> U __deregister_frame_info U __register_frame_info
Marcelo> 1000s-O2 is a program compiled with g77 (egcs)
Marcelo> $ ldd ./1000s-O2
Marcelo> libm.so.6 => /lib/libm.so.6 (0x4000f000) libc.so.6
Marcelo> => /lib/libc.so.6 (0x40027000) /lib/ld-linux.so.2 =>
Marcelo> /lib/ld-linux.so.2 (0x40000000)
Marcelo> so, register_frame_info comes from libc.
>> So it looks like a completely egcs only problem.
Marcelo> egcs puts the call to __register_frame_info in the binary,
Marcelo> but libc provides the function... or am I missing something
Marcelo> about how the linker works?
You are missing something about how the linker works, but so did I
actually.
the gcc binary when calling the linker puts three libs as the last
three on the link line '-lc -lgcc -lc' -lgcc is the one I wrote
about in my last message. It's a static lib and anything in it is
used statically so no symbols will be pulled from a dynamic lib.
It looks like (from the next message in this series) that -lm actually
contains this symbol. So anything linking with -lm will get the
symbol from there first before libgcc.a has a chance to provide it.
That's probably a bad idea and is causing our problems.
If the symbol didn't live in libm.so.6 then it'd be statically linked
and the binary would work anywhere. So I guess the question is: Why
does libm have this symbol defined in it?
Dres
--
@James LewisMoss <dres@ioa.com> | Blessed Be!
@ http://www.ioa.com/~dres | Linux is kewl!
@"Argue for your limitations and sure enough, they're yours." Bach
Reply to: