This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Current glibc cvs-head produces undefined symbols in libc.a
- From: Nicholas Wourms <nwourms at myrealbox dot com>
- To: libc-alpha at sources dot redhat dot com
- Date: Wed, 30 Apr 2003 08:49:35 -0400
- Subject: Current glibc cvs-head produces undefined symbols in libc.a
My system is a dual athlon-mp running linux with
kernel-2.4.20 patched with the RedHat NPTL patches
(threading backport, etc.).
This started happening over the last couple of weeks or so.
I am currently using:
gcc-3.3 (as of 12:00 EDT today)
binutils HEAD (as of 11:00 EDT today)
I've compiled and installed glibc snapshot taken from cvs
today after Uli's fpu commits. I then recompiled gcc
against that snapshot.
The problem I'm experiencing happens when I try to link an
executable statically (gcc -static). This can be seen in
something as trivial as Hello World. Gcc calls ld to link
in libgcc.a, libgcc_eh.a, and libc.a during the process to
make the binary. At this point it fails, complaining that
there is an undefined reference to "dl_iterate_phdr" in
unwind-dw2-fde-glibc.o in the archive libgcc_eh.a. Well,
I'm assuming that the reference should be resolved by the
symbol in the libc.a archive, which it does contain.
However, while inspecting the objects of the libc.a archive,
I noticed many undefined references _GLOBAL_OFFSET_TABLE_
w/o any corresponding relocation records indicating that
they were resolved (while all the other undefined are
resolved through relocations and noted in the relocation
records). _GLOBAL_OFFSET_TABLE_ is undefined and unresolved
in the static object file containing the dl_iterate_phdr
function, which leads me to believe that this is the cause
of the trouble.
To further test this theory, I reverted to both gcc-3.2.3
and binutils-2.13.90.0.18, recompiling glibc and then
gcc-3.2.3 once more. The results are the same,
_GLOBAL_OFFSET_TABLE_ is still undefined in libc.a and no
relocation records indicate it was ever resolved.
I then went over and examined a machine using glibc-2.3.1
(no NPTL/TLS), and found that libc.a contained no such
references to the _GLOBAL_OFFSET_TABLE_ symbol.
Google was not to helpful on this particular symbol, since
the hits refered to discussions which happened quite a long
time ago, most of which weren't about linux anyhow. I could
very well be wrong about some of my assumptions, so I
apologize in advance if this isn't a glibc issue.
Cheers,
Nicholas