[lug] (no subject)
blug-mail at duboulder.com
Wed May 18 16:05:56 MDT 2005
Dan Ferris wrote:
> This particular problem is beginnig to drive me insane. The is on both
> Fedora Core 3 boxes AND our Red Hat Enterprise 3 boxes:
> (1) [~] > gcc test.c -o test.o
> /lib/libc.so.6: undefined reference to `_dl_check_caller at GLIBC_PRIVATE'
> /lib/libc.so.6: undefined reference to `_dl_tls_symaddr at GLIBC_PRIVATE'
> collect2: ld returned 1 exit status
It looks like in the link phase there is reference from libc to these undefined
symbols. On a gentoo/amd64 system I have:
/lib/libc.so.6 --> libc-2.3.4.so
/lib64/ld-linux-x86-64.so.2 --> /lib64/ld-linux-x86-64.so.2
The times on /lib/libc-2.3.4.so and /lib64/ld-linux-x86-64.so.2
are the same. If there was anything really wrong with these libs
your system would be borked as no dynamically linked executables
would be successfully loaded by the kernel (e.g. bash). I've done
this fiddling with the libs.
If the gcc link phase is using a different set of libs than when
programs are loaded by the kernel you could see strangeness. Items
that affect where libs are picked up are LD_LIBRARY_PATH, ldconfig
and the gcc config. If you have the gcc-config program:
will give you an idea of where gcc is pulling in the libs.
Has there been a change in gcc? I have:
libc.so.6 => /lib/tls/libc.so.6 (0x00002aaaaabc1000)
where /lib/tls/libc.so.6 --> libc-2.3.4.so
> This error comes from any box that includes stdio.h or anything else
> that needs glibc.
> glibc hasn't been touched since like December. Any ideas to make this
> problem go away would be appreciated.
> Web Page: http://lug.boulder.co.us
> Mailing List: http://lists.lug.boulder.co.us/mailman/listinfo/lug
> Join us on IRC: lug.boulder.co.us port=6667 channel=#colug
More information about the LUG