Re: Current glibc cvs-head produces undefined symbols in libc.a

["Stefan Jones" <cretin at gentoo dot org>]

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.