This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: Current glibc cvs-head produces undefined symbols in libc.a
- From: "Stefan Jones" <cretin at gentoo dot org>
- To: "Nicholas Wourms" <nwourms at myrealbox dot com>
- Cc: libc-alpha at sources dot redhat dot com
- Date: Wed, 30 Apr 2003 17:37:26 +0100 (BST)
- Subject: Re: Current glibc cvs-head produces undefined symbols in libc.a
- References: <3EAFC65F.7010006@myrealbox.com>
I am not claiming I know anything but there is the link which explains it
all,
http://www.ussg.iu.edu/hypermail/linux/kernel/0304.3/0377.html
My take is the following:
It seems the kernel now provides some of the usercode to get things done
like the recent sysenter call addition. This code doesn't have a static
library (as it would defeat the purpose I suppose), thus cannot be
statically compiled as of now.
Stefan
Nicholas Wourms said:
> 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.