Fun fun fun. :-) Andrew Benton wrote: > Then an error due to a problem with gcc: > > /mnt/lfs/sources/glibc-build/resolv/libresolv_pic.a(gethnamaddr.os): In > function `getanswer': > /mnt/lfs/sources/glibc-2.16.0/resolv/gethnamaddr.c:180: undefined reference > to `__stack_chk_guard' > /mnt/lfs/sources/glibc-2.16.0/resolv/gethnamaddr.c:483: undefined reference > to `__stack_chk_guard' > /mnt/lfs/sources/glibc-build/resolv/libresolv_pic.a(gethnamaddr.os): In > function `res_gethostbyaddr': > /mnt/lfs/sources/glibc-2.16.0/resolv/gethnamaddr.c:644: undefined reference > to `__stack_chk_guard' > /mnt/lfs/sources/glibc-2.16.0/resolv/gethnamaddr.c:783: undefined reference > to `__stack_chk_guard' > /mnt/lfs/sources/glibc-build/resolv/libresolv_pic.a(gethnamaddr.os): In > function `__GI_res_gethostbyname2': > /mnt/lfs/sources/glibc-2.16.0/resolv/gethnamaddr.c:510: undefined reference > to `__stack_chk_guard' > /mnt/lfs/sources/glibc-build/resolv/libresolv_pic.a(gethnamaddr.os):/mnt/lfs/sources/glibc-2.16.0/resolv/gethnamaddr.c:636: > more undefined references to `__stack_chk_guard' follow > collect2: error: ld returned 1 exit status > make[2]: *** [/mnt/lfs/sources/glibc-build/resolv/libresolv.so] Error 1 > make[2]: *** Waiting for unfinished jobs.... > make[2]: Leaving directory `/mnt/lfs/sources/glibc-2.16.0/resolv' > make[1]: *** [resolv/others] Error 2 > make[1]: Leaving directory `/mnt/lfs/sources/glibc-2.16.0' > make: *** [all] Error 2 > > Fixed by this sed in the gcc source before the first pass of gcc: > > sed -i '/k prot/agcc_cv_libc_provides_ssp=yes' gcc/configure
Shouldn't that use the configparms file that we already edit? :-) Or doesn't that work for some reason? I thought we used to dump ac_cv_libc_something into that to prepare the cache. > There's lots of gets removal breakage. (Blame C11. :-) ) > diffutils-3.2 fails to build: > > CC exitfail.o > In file included from exclude.c:31:0: > ./stdio.h:1012:1: error: 'gets' undeclared here (not in a function) > > Fixed with a sed: > sed -i '/gets is a security hole/d' lib/stdio.in.h From the line right before the one this is removing, in the large block comment: > It is very rare that the developer ever has full control of stdin, > so any use of gets warrants an unconditional warning. Assume it is > always declared, since it is required by C89. It's required by C89, but deprecated in C99, and removed in C11 -- and glibc follows C11 by removing the declaration if you're asking for that standard version. (Which is fun since libstdc++ needs it if you're asking for a new-enough C++, and was the cause of a bunch of scrambling earlier this year.) So I think this should be changed instead to only "#undef gets" and then "_GL_WARN_ON_USE" if C11 is in use. ...Or do what newer gnulib versions did: http://lists.gnu.org/archive/html/bug-gnulib/2012-03/msg00186.html and add an "#if HAVE_RAW_DECL_GETS" check, along with possibly newer configury. Hmm. Be interesting to see if that patch works when applied directly. On the other hand, why are all these packages using gnulib headers in the first place, instead of the system ones? Don't we have a glibc and a gcc that works with it installed? If they don't use the local gnulib stdio.h, they won't run into this issue... > test-installation.pl failed with an error: > > root:/sources/glibc-2.16.0# CC="gcc" /usr/bin/perl > scripts/test-installation.pl /sources/glibc-build/ > Unmatched ( in regex; marked by <-- HERE in m/$( <-- HERE if > $(abi-64-ld-soname),$(abi-64-ld-soname),ld/ at scripts/test-installation.pl > line 172, <LDD> line 1. Is this an issue with the output of ldd? If you can find the ldd that this glibc built (preferably not the one in the chapter5 /tools/bin), what happens if you run it on any of the /tmp/tst-prg* files? (Assuming those are still around. If not, you can rebuild one by compiling the following source...) $ cat <<'EOF' >/tmp/tst-prg.c #include <stdio.h> #include <stdlib.h> int main(void) { printf ("Your new glibc installation seems to be ok.\n"); exit (0); } EOF $ grep -v ^all-sonames /sources/glibc-build/soversions.mk <Then for each line there that matches ^lib, if it's not nss_ldap or db1 or nss1_* or thread_db or nss_test1 or libgcc_s, add a -l<libname> below. Also find the target of the ld.so symlink.> $ gcc /tmp/tst-prg.c -o /tmp/tst-prg <-l stuff from above> Because the test-installation.pl script simply builds a tiny C program with "all" the glibc libraries, and runs ldd on it. Also it run sthis on the contents of soversions.mk: if (/^ld\.so/) { ($ld_so_name, $ld_so_version)= /=(.*)\.so\.(.*)$/; } so it might be useful to ensure the file's contents still work with that regexp, not extracting something silly that would cause the later syntax error. > I should confess that (as I'm a devotee of the Klingon School of > Programming) I didn't run any of the tests, so there may be some more > bugs under those rocks. Heh. That test-installation.pl issue seems like it might be pointing at something busted in the system, but it might also be that a file or a file's autogen instructions changed in an incompatible way. The $(abi-64-ld-soname) stuff seems rather wrong; it looks like a Makefile variable substitution that didn't happen. The gnulib stuff as well, might be pointing at a problem in the build system, if various tools are thinking that the glibc headers are not compatible with the system compiler, as the comments seem to indicate. If that's happening we should try to fix it.
signature.asc
Description: OpenPGP digital signature
-- http://linuxfromscratch.org/mailman/listinfo/lfs-dev FAQ: http://www.linuxfromscratch.org/faq/ Unsubscribe: See the above information page
