Yeah, it's not the symlink.
The "cc --version" is
3.4.4. As is "gcc."
A snippet of config.log reads:
Code:
checking for gcc... gcc
checking for C compiler default output file name... configure: error: C compiler cannot create executables
See `config.log' for more details.
...
configure:2251: checking for C compiler default output file name
configure:2254: gcc conftest.c >&5
/tools/lib/libc.so.6: undefined reference to `_rtld_global_ro@GLIBC_PRIVATE'
/tools/lib/libc.so.6: undefined reference to `___tls_get_addr@GLIBC_2.3'
collect2: ld returned 1 exit status
configure:2257: $? = 1
configure: failed program was:
| /* confdefs.h. */
|
| #define PACKAGE_NAME "GNU Awk"
| #define PACKAGE_TARNAME "gawk"
| #define PACKAGE_VERSION "3.1.4"
| #define PACKAGE_STRING "GNU Awk 3.1.4"
| #define PACKAGE_BUGREPORT "bug-gawk@gnu.org"
| #define PACKAGE "gawk"
| #define VERSION "3.1.4"
| /* end confdefs.h. */
(followed by a null C-program)
And here are some symlinks...
Code:
bash-2.05b$ locate libc.so.6
/lib/i686/libc.so.6
/lib/libc.so.6
/mnt/hd4/lfs/tools/lib/libc.so.6
/mnt/hd4/lfs/glibc-build/libc.so.6
bash-2.05b$ ls -l /lib/libc.so.6
lrwxrwxrwx ... /lib/libc.so.6 -> libc-2.2.93.so {edited "..." for clarity}
bash-2.05b$ ls -l /mnt/hd4/lfs/glibc-build/libc.so.6
lrwxrwxrwx ... /mnt/hd4/lfs/glibc-build/libc.so.6 -> libc.so
bash-2.05b$ ls -l /mnt/hd4/lfs/tools/lib/libc.so.6
lrwxrwxrwx ... /mnt/hd4/lfs/tools/lib/libc.so.6 -> libc-2.3.5.so
{The /tools/lib as seen by user "lfs" is this last one...}
Hmm... So it would seem from the output (last line...) that we are referencing
libc-2.3.5.so, by means of the symlink, and we are properly referring to the libc of the lfs user, not the host, as expected. Which is rather curious because you would expect a symbol like `___tls_get_addr@GLIBC_2.3' ... unless the root cause of the problem is really "
__tls_get_addr" instead of the glibc version. But this is an attempt to compile a dummy program. It isn't trying to
do anything.
Very puzzling.
