Re: binaries compiled on slink don't run anywhere else
Oleg Krivosheev <kriol@fnal.gov> writes:
> Hi,
<SNIP>
> No, that's not true
>
> __register_frame_info is defined in libc AND libgcc, but because
> libc is linked first, you get __register_frame_info symbol
> resolved. The only fix i can think about:
>
> 1. out of libgcc create small library called libframe and
> put it into egcc subdir (/usr/lib/gcc-lib/i486-linux/egcs-2.91.58/)
>
> 2. modify egcc spec so libframe will be linked BEFORE libc
>
> 3. provide libframe.so in order to be able to run slink
> binaries on RH and such via LD_LIBRARY_PRELOAD trick
Ew. Well, first let me say that I can't test this solution as my libc
is still at 2.0.7u-4, (Stupid ppp line always getting busy signals)
but what about weakening the __register_frame_info symbol in libc?
You know, with a:
objcopy -W __register_frame_info /lib/libc-2.0.7.so
?
This should solve the problem temporarily, I'd think. Since
__register_frame_info would then be only weakly defined in libc, but
strongly defined in libgcc, the static version would get used.
Now, I notice that when my gcc links, links with the arguments: (cc -v
is your friend)
ld -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 -o tmp /usr/lib/crt1.o /usr/lib/crti.o /usr/lib/gcc-lib/i486-linux/2.7.2.3/crtbegin.o -L/usr/lib/gcc-lib/i486-linux/2.7.2.3 /tmp/ccc27427 -lgcc -lc -lgcc /usr/lib/gcc-lib/i486-linux/2.7.2.3/crtend.o /usr/lib/crtn.o
Note the double inclusion of -lgcc; this means libgcc gets used
_before_ libc. I'm not certain what it is about the specs file that
causes this, but it is a good thing, and if we could get egcs to just
do this the problem would then go away. (So though the temporary fix
may be found by mucking with libc, the permanent fix is through
mucking with egcs)
Reply to: