Hi, Something has changed in /var/tmp/portage/glibc-2.3.5-r2/work/build-default-i686-pc-linux-gnu-nptl/csu/version-info.h during 2006-02-23: cat /var/tmp/portage/glibc-2.3.5-r2/work/build-default-i686-pc-linux-gnu-nptl/csu/version-info.h "Compiled on a Linux 2.6.11 system on 2006-02-23.\n" "Available extensions: " " GNU libio by Per Bothner\n" " crypt add-on version 2.1 by Michael Glad and others\n" " Native POSIX Threads Library by Ulrich Drepper et al\n" " The C stubs add-on version 2.1.2.\n" " GNU Libidn by Simon Josefsson\n" " BIND-8.2.3-T5B\n" " NIS(YP)/NIS+ NSS modules 0.19 by Thorsten Kukuk\n" There are 2 missing '"' on 2nd and 3rd line This is the error report from gcc: In file included from version.c:33: /var/tmp/portage/glibc-2.3.5-r2/work/build-default-i686-pc-linux-gnu-nptl/csu/version-info.h:2: error: missing terminating " character /var/tmp/portage/glibc-2.3.5-r2/work/build-default-i686-pc-linux-gnu-nptl/csu/version-info.h:3: error: missing terminating " character version.c:40: error: parse error before string constant make[2]: *** [/var/tmp/portage/glibc-2.3.5-r2/work/build-default-i686-pc-linux-gnu-nptl/csu/version.o] Error 1 make[2]: *** Waiting for unfinished jobs.... make[2]: Leaving directory `/var/tmp/portage/glibc-2.3.5-r2/work/glibc-2.3.5/csu' make[1]: *** [csu/subdir_lib] Error 2 make[1]: Leaving directory `/var/tmp/portage/glibc-2.3.5-r2/work/glibc-2.3.5' make: *** [all] Error 2 !!! ERROR: sys-libs/glibc-2.3.5-r2 failed. !!! Function toolchain-glibc_src_compile, Line 233, Exitcode 2 !!! (no error message) !!! If you need support, post the topmost build error, NOT this status message.
My bug report isn't very accurate. I'm still investigating because the same issue happens in glibc-2.3.5-r3 and it looks like the problem is somewhere else, cause I've just compile glibc-2.3.5-r2 inside a gentoo vmware image without any problems. Lowering severity & priority.
The problem is with your shell. Please try re-installing bash and making sure /bin/sh points to that, instead of ksh/zsh/some other shell. (I ran into this problem on a non-Gentoo system myself.)
OK, I finally found what the problem is. In this particulary system I've replaced /bin/sh for /bin/dash. In the file "/var/tmp/portage/glibc-2.3.5-r2/work/glibc-2.3.5/csu/Makefile" we have this piece of code for generating "/var/tmp/portage/glibc-2.3.5-r2/work/build-default-i686-pc-linux-gnu-nptl/csu/version-info.h" <START CODE> files="$(all-Banner-files)"; \ if test -n "$$files"; then \ echo "\"Available extensions:\\n\""; \ sed -e '/^#/d' -e 's/^[[:space:]]*/ /' \ -e 's/^\(.*\)$$/\"\1\\n\"/' $$files; \ fi) > $@T <END CODE> This Makefile belongs do glibc, and it's not being changed by gentoo. The problem with dash is that dash have an internal echo function that *always* interprets special "chars" like "\n". It's the same as "/bin/echo -e". Maybe other shells have the same behaviour (I only use bash & dash), so my sugestion is to force a sane shell in the environment of the ebuild process. I've done some tests changing the echo line and didn't get a universal way with sane interpretation of the echo command. Example: *** In dash *** # echo "\"Available extensions:\\n\"" "Available extensions: " # echo '"Available extensions:\\n"' "Available extensions:\n" # echo -e '"Available extensions:\\n"' -e "Available extensions:\n" # echo '"Available extensions:\n"' "Available extensions: " *** In bash *** # echo "\"Available extensions:\\n\"" "Available extensions:\n" # echo '"Available extensions:\\n"' "Available extensions:\\n" # echo -e '"Available extensions:\\n"' "Available extensions:\n" # echo '"Available extensions:\n"' "Available extensions:\n" This is only my 2nd issue regarding problems with dash. Maybe I should give up on it, but what about other shells?... Regards. PS: Harald I only saw your post when I was commiting the bug. thks
This is fixed upstream, by the way, with http://sources.redhat.com/cgi-bin/cvsweb.cgi/libc/csu/Makefile.diff?r1=1.75&r2=1.76&cvsroot=glibc
thanks Harald, added fix from upstream to patch tarballs Rodrigo: dont take this as meaning changing /bin/sh to different shells is generally supported ... if upstream didnt make the change, i would have propbably marked this bug INVALID ...
