Undefined __register_frame_info problem

Ben Woodard bwoodard@cisco.com
Wed Apr 22 13:15:00 GMT 1998


Thank you very much for your response. This one seems to be a bit of a
stumper. I get the feeling that it goes way over most people's
heads. I have included Einar Rune Haugne on the cc: line because he
wrote me stating that he is having exactly the same problem and was
interested in the solution.

> 	/home/bwoodard/WorkArea/easysnmp/getprsnmpinfo: error in loading shared libraries
> 	: undefined symbol: __register_frame_info
> 
> 	This doesn't happen when I compile things with the original gcc that
> 	is on my system. 
> 
> The original gcc is probably gcc 2.7.2.3, which does not have this function.

correct!!

[bwoodard@trill fetchmail-4.4.1]$ /usr/bin/gcc --version
2.7.2.3


> 
> 	It looks like __register_frame_info is defined in frame.c but it
> 	doesn't seem to have been compiled. 
> 
> It is compiled into libgcc.a.  If you compile a shared library with egcs-1.0.2
> then you need to link it with the egcs-1.0.2 libgcc.a.
> 
> The above problem could happen if you compiled a shared library with egcs-1.0.2
> and then tried to link it with gcc 2.7.2.3.
> 

That doesn't seem to be the case. All the programs on my system that
exhibit this problem do not use any shared libraries except for those
included within glibc which was installed on the system as a update
from redhat. I do not know what compiler glibc was compiled with but
the libcc.a that came with it does not contain the
__register_frame_info symbol.

[bwoodard@trill fetchmail-4.4.1]$ nm /usr/lib/gcc-lib/i386-redhat-linux/2.7.2.3/libgcc.a | grep __register_frame_info

I am not doing anything weird compiling these programs like compiling
with egcs and linking with gcc.

> If you are compiling and linking everything with egcs-1.0.2, then check to
> make sure that the right libgcc.a library is being linked in, and that it
> does contain the frame.o object file.

I did a:

[bwoodard@trill fetchmail-4.4.1]$ strace -f make 2>/tmp/file
...
[bwoodard@trill fetchmail-4.4.1]$ grep libgcc.a /tmp/file
[pid 32187] open("/usr/local/lib/gcc-lib/i586-pc-linux-gnu/egcs-2.90.27/libgcc.a", O_RDONLY) = 6
[pid 32187] open("/usr/local/lib/gcc-lib/i586-pc-linux-gnu/egcs-2.90.27/libgcc.a", O_RDONLY) = 10
[bwoodard@trill fetchmail-4.4.1]$ nm /usr/local/lib/gcc-lib/i586-pc-linux-gnu/egcs-2.90.27/libgcc.a | grep __register_frame_info
000007b8 T __register_frame_info
00000830 T __register_frame_info_table    

and so I believe that I am linking against the right version of
libgcc.a.  Could it be a problem with what linker egcs is calling at
certain times because this looks a bit strange:

[bwoodard@trill fetchmail-4.4.1]$ grep -B 1 "/ld\"" /tmp/file
...
[pid 32209] wait4(-1,  <unfinished ...>
[pid 32210]
execve("/usr/local/lib/gcc-lib/i586-pc-linux-gnu/egcs-2.90.27/ld",
["/usr/local/lib/gcc-lib/i586-pc-l"..., "-m", "elf_i386",
"-dynamic-linker", "/lib/ld-linux.so.2", "-o", "fetchmail", "-s",
"/usr/local/lib/crt1.o", "/usr/local/lib/crti.o",
"/usr/local/lib/gcc-lib/i586-pc-l"...,
"-L/usr/local/lib/gcc-lib/i586-pc"...,
"-L/usr/local/i586-pc-linux-gnu/l"..., "-L/usr/local/lib",
"rcfile_y.o", "rcfile_l.o", ...], [/* 33 vars */]) = 0 
--
[pid 32211] execve(ptrace: umoven: Input/output error
0x8056db8, ["/usr/bin/ld", "-m", "elf_i386", "-dynamic-linker",
"/lib/ld-linux.so.2", "-o", "fetchmail", "-s",
"/usr/local/lib/crt1.o", "/usr/local/lib/crti.o",
"/usr/local/lib/gcc-lib/i586-pc-l"...,
"-L/usr/local/lib/gcc-lib/i586-pc"...,
"-L/usr/local/i586-pc-linux-gnu/l"..., "-L/usr/local/lib",
"rcfile_y.o", "rcfile_l.o", ...], [/* 35 vars */]) = 0 

Notice that the first time it calls the correct ld out of
/usr/local... but the second time it calls /usr/bin/ld. 

The parent proccess of the first link is 32209 which was started with
this exec:

[pid 32209] execve("/usr/local/bin/gcc", ["gcc", "-s", "rcfile_y.o",
"rcfile_l.o", "socket.o", "getpass.o", "pop2.o", "pop3.o", "imap.o",
"etrn.o", "fetchmail.o", "env.o", "options.o", "daemon.o", "driver.o",
"rfc822.o", ...], [/* 29 vars */]) = 0  

The parent process of the second link is 32210 which was started with
this exec:

[pid 32210]
execve("/usr/local/lib/gcc-lib/i586-pc-linux-gnu/egcs-2.90.27/ld",
["/usr/local/lib/gcc-lib/i586-pc-l"..., "-m", "elf_i386",
"-dynamic-linker", "/lib/ld-linux.so.2", "-o", "fetchmail", "-s",
"/usr/local/lib/crt1.o", "/usr/local/lib/crti.o",
"/usr/local/lib/gcc-lib/i586-pc-l"...,
"-L/usr/local/lib/gcc-lib/i586-pc"...,
"-L/usr/local/i586-pc-linux-gnu/l"..., "-L/usr/local/lib",
"rcfile_y.o", "rcfile_l.o", ...], [/* 33 vars */]) = 0

which sort of says to me that for some reason at some point
/usr/local/lib/gcc-lib/i586-pc-linux-gnu/egcs-2.90.27/ld is calling
/usr/bin/ld rather than itself. I thought that this might be a path
problem where it simply execs the first one on my path but
/usr/local/bin is ahead of /usr/bin in my path:

[bwoodard@trill fetchmail-4.4.1]$ echo $PATH
/home/bwoodard/bin:/usr/local/bin:/bin:/usr/bin:/usr/X11/bin:/opt/bin:/usr/bin/mh:/opt/kde/bin

So what do you think? Could this be a bug in the ld that comes with
egcs-1.0.2? What should I look at next? 

-ben



More information about the Gcc-bugs mailing list