[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