[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: binaries compiled on slink don't run anywhere else



Hi,

   > That's where I'm confused.
   > 
   > $ nm 1000s-O2 | grep register_frame_info
   > 		   U __deregister_frame_info
   > 		   U __register_frame_info
   > 
   > 1000s-O2 is a program compiled with g77 (egcs)
   > 
   > $ ldd ./1000s-O2
   > 		  libm.so.6 => /lib/libm.so.6 (0x4000f000)
   > 		  libc.so.6 => /lib/libc.so.6 (0x40027000)
   > 		  /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
   > 
   > so, register_frame_info comes from libc.

   The __register_frame_info is provided by the libgcc.a that comes with
   egcs. Since the symbol is still undefined in the linked binary, I
   guess that the linker didn't link with that libgcc.a at all, or found
   a wrong one (the one from gcc 2.7.2.3).

   BTW, my libc.so.6 (2.0.7u-4 on m68k) does NOT provide
   __register_frame_info. I guess it slips into the library if it is
   compiled with egcs. I don't think it's meant to be exported, but in
   the end it is exported, so your program runs.

   But the real error must be in the link step of your 1000s-O2 program.

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

cheers

OK

ps i don't think recompilation of 2000+ packages in slink is necessary




Reply to: