[Clfs-support] Problem with EGLIBC in 10.7 on x86_64-Pure64
Chris J. Breisch
chris at breisch.org
Wed Jan 16 04:47:20 PST 2013
Frankly, I'm surprised to be getting any errors in Chapter 10. I figured
things would be smooth sailing from here on out, since I'm booted into
the target environment.
I'm using the current development snapshot of the CLFS book, version
20121227-x86_64-Pure64.
Anyway, when linking libresolv.so, I get the following errors:
/native/eglibc/build/resolv/libresolv_pic.a(gethnamaddr.os): In function
`getanswer':
/native/eglibc/eglibc-2.15/resolv/gethnamaddr.c:180: undefined reference
to `__stack_chk_guard'
/native/eglibc/eglibc-2.15/resolv/gethnamaddr.c:483: undefined reference
to `__stack_chk_guard'
/native/eglibc/build/resolv/libresolv_pic.a(gethnamaddr.os): In function
`res_gethostbyaddr':
/native/eglibc/eglibc-2.15/resolv/gethnamaddr.c:644: undefined reference
to `__stack_chk_guard'
/native/eglibc/eglibc-2.15/resolv/gethnamaddr.c:783: undefined reference
to `__stack_chk_guard'
/native/eglibc/build/resolv/libresolv_pic.a(gethnamaddr.os): In function
`__GI_res_gethostbyname2':
/native/eglibc/eglibc-2.15/resolv/gethnamaddr.c:510: undefined reference
to `__stack_chk_guard'
/native/eglibc/build/resolv/libresolv_pic.a(res_debug.os):/native/eglibc/eglibc-2.15/resolv/res_debug.c:287:
more undefined references to `__stack_chk_guard' follow
The command being used to link is:
gcc -shared -static-libgcc -Wl,-O1 -Wl,-z,defs
-Wl,-dynamic-linker=/lib64/ld-linux-x86-64.so.2
-B/native/eglibc/build/csu/
-Wl,--version-script=/native/eglibc/build/libresolv.map
-Wl,-soname=libresolv.so.2 -Wl,-z,combreloc -Wl,-z,relro
-Wl,--hash-style=both -L/native/eglibc/build
-L/native/eglibc/build/math -L/native/eglibc/build/elf
-L/native/eglibc/build/dlfcn -L/native/eglibc/build/nss
-L/native/eglibc/build/nis -L/native/eglibc/build/rt
-L/native/eglibc/build/resolv -L/native/eglibc/build/crypt
-L/native/eglibc/build/nptl
-Wl,-rpath-link=/native/eglibc/build:/native/eglibc/build/math:/native/eglibc/build/elf:/native/eglibc/build/dlfcn:/native/eglibc/build/nss:/native/eglibc/build/nis:/native/eglibc/build/rt:/native/eglibc/build/resolv:/native/eglibc/build/crypt:/native/eglibc/build/nptl
-o /native/eglibc/build/resolv/libresolv.so -T
/native/eglibc/build/shlib.lds /native/eglibc/build/csu/abi-note.o
-Wl,--whole-archive /native/eglibc/build/resolv/libresolv_pic.a
-Wl,--no-whole-archive /native/eglibc/build/elf/interp.os
/native/eglibc/build/libc.so /native/eglibc/build/libc_nonshared.a
-Wl,--as-needed /native/eglibc/build/elf/ld.so -Wl,--no-as-needed
This appears to be because the files in eglibc-2.15/resolv have been
compiled with the '-fstack-protector' switch, but neither that switch
nor '-lssp' is supplied to the linker.
In fact, if I add "-v, -Wl,--verbose" to the command, I see that the
linker doesn't even attempt to bring in libssp.
I could add '-lssp' to the link statement, but I wonder if that's
correct. libssp.so is in /tools, and I was under the impression that we
don't want that brought in.
It seems to me that either I should tell configure that I don't want to
use stack protection, or that I should have configured GCC that way all
the way back in 5.17. Pretty sure that either of those would work. And
while I'd rather just fix it now, rather than essentially starting over,
I'm wondering if the whole thing is a symptom of my doing something else
wrong.
I found a thread in the LFS archives from two years ago where a person
had the exact same problem. From reading the thread, it doesn't appear
that a resolution was ever discovered.
http://www.mail-archive.com/lfs-support@linuxfromscratch.org/msg13219.html
Any thoughts, or should I plan on starting over from scratch?
--
Chris J. Breisch<http://www.sports-gazer.com>
More information about the Clfs-support
mailing list