Same environment and workaround as in this report: http://bugs.gentoo.org/show_bug.cgi?id=252213 The `emerge --oneshot grep' step pulls in pkgconfig and libpcre. The latter fails to emerge. The last part of the console output goes i686-pc-linux-gnu-g++ -O2 -march=i686 -pipe -Wl,-O1 -o .libs/pcre_stringpiece_unittest pcre_stringpiece_unittest.o ./.libs/libpcrecpp.so /local/scratch/portage/dev-libs/libpcre-7.8/work/pcre-7.8/.libs/libpcre.so /usr/lib/gcc/i586-suse-linux/4.1.2/libstdc++.so -lz /usr/lib/libbz2.so -Wl,--rpath -Wl,/local/tmp/o/usr/lib -Wl,--rpath -Wl,/usr/lib/gcc/i586-suse-linux/4.1.2 ./.libs/libpcrecpp.so: undefined reference to `std::basic_ostream<char, std::char_traits<char> >& std::__ostream_insert<char, std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&, char const*, int)' collect2: ld returned 1 exit status make[1]: *** [pcre_stringpiece_unittest] Error 1 make[1]: *** Waiting for unfinished jobs.... i686-pc-linux-gnu-g++ -O2 -march=i686 -pipe -Wl,-O1 -o .libs/pcre_scanner_unittest pcre_scanner_unittest.o ./.libs/libpcrecpp.so /local/scratch/portage/dev-libs/libpcre-7.8/work/pcre-7.8/.libs/libpcre.so /usr/lib/gcc/i586-suse-linux/4.1.2/libstdc++.so -lz /usr/lib/libbz2.so -Wl,--rpath -Wl,/local/tmp/o/usr/lib -Wl,--rpath -Wl,/usr/lib/gcc/i586-suse-linux/4.1.2 ./.libs/libpcrecpp.so: undefined reference to `std::basic_ostream<char, std::char_traits<char> >& std::__ostream_insert<char, std::char_traits<char> >(std::basic_ostream<char, std::char_traits<char> >&, char const*, int)' collect2: ld returned 1 exit status make[1]: *** [pcre_scanner_unittest] Error 1 mv -f .deps/pcrecpp_unittest.Tpo .deps/pcrecpp_unittest.Po make[1]: Leaving directory `/local/scratch/portage/dev-libs/libpcre-7.8/work/pcre-7.8' make: *** [all] Error 2 * ERROR: dev-libs/libpcre-7.8 failed: * emake failed * * Call stack: * ebuild.sh: 49: <call src_compile> * environment:2448: emake all || die "emake failed" * * If you need support, post the topmost build error, and the call stack if relevant. * build log: '/local/scratch/portage/dev-libs/libpcre-7.8/temp/build.log' * ebuild environment: '/local/scratch/portage/dev-libs/libpcre-7.8/temp/environment' * S: '/local/scratch/portage/dev-libs/libpcre-7.8/work/pcre-7.8'
This problem was shadowed by http://bugs.gentoo.org/show_bug.cgi?id=253120 for a while. Having applied the LZMA workaround this is once again the point where bootstrapping stops for me.
I tried to mask libpcre-7.8 just to see if it would help. This causes libpcre-7.7-r1 to be emerged instead. However, the emerge fails in very much the same way.
Trying another workaround now: Skip the `emerge --oneshot grep' step altogether. Will report the outcome tomorrow.
This worked, perhaps. Bootstrapping stopped at a later stage, *probably* not related to "grep". I will describe that problem in a separate report.
The *probably* unrelated problem is here: http://bugs.gentoo.org/show_bug.cgi?id=255019
Well, USE=pcre is in the new profiles. We could disable that too until the user gets a working prefix running. Would that be acceptable?
It is to me. Perhaps we should disable the entire bunch of keywords that the new Linux profiles add during the bootstrap phase.
--- bootstrap-solaris.xml 15 Feb 2009 10:39:45 -0000 1.41 +++ bootstrap-solaris.xml 19 Feb 2009 23:37:46 -0000 @@ -164,7 +164,7 @@ dependancies, so we disable them until later. </p> <pre caption="Disable USE flags"> -$ <i>export USE="-nls -berkdb -gdbm -fortran"</i> +$ <i>export USE="-nls -berkdb -gdbm -fortran -pcre"</i>
