This comment refers to the February 4, 2007 version of the document pointed to by the URL. It appears that building the 'grep' command in step 1.3 may fail. I noticed it failing with the following diagnostic: gcc -O2 -pipe -o grep grep.o dfa.o kwset.o search.o grepmat.o ../lib/libgreputils.a Undefined first referenced symbol in file libintl_gettext dfa.o ld: fatal: Symbol referencing errors. No output written to grep collect2: ld returned 1 exit status gmake[2]: *** [grep] Error 1 gmake[2]: Leaving directory `/opt/gentoo/tmp/var/tmp/grep-2.5.1a/grep-2.5.1a/src' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/opt/gentoo/tmp/var/tmp/grep-2.5.1a/grep-2.5.1a' gmake: *** [all] Error 2 Besides this there was a warning about a "makeinfo" problem. I was able to get rid of the "makeinfo" warning by installing a binary "texinfo" package (version 4.8 from http://www.bolthole.com/solaris/pkg-get.html). However, I could not find a workaround for the "libintl_gettext" problem. I therefore installed "ggrep" (GNU grep 2.5) from http://www.bolthole.com/solaris/pkg-get.html, and added symlinks named grep, egrep, fgrep pointing to ggrep, gegrep, fegrep respectively. In this way I could move forward with GNU versions of grep/fgrep/egrep available towards the end of my PATH. Later on, just after the "emerge --oneshot --nodeps sys-apps/baselayout-prefix" step, I could successfully run "emerge --oneshot grep" and start using the Gentoo version of grep. Not sure how this should be classified. One way of looking at it is to say that GNU grep is a prerequisite of the entire bootstrap process, and that a binary version must be installed. A more satisfactory approach would be to defer the building of grep to some point beyond step 1.3? It remains to be tried out if that is indeed possible; there is the tisk that some build step requires GNU grep before it can be successfully emerged. Reproducible: Didn't try uname -a produces: SunOS 5.10 Generic_118855-14 i86pc i386 i86pc Solaris In this case the bootstrap process was done as an unprivileged user (except for the installation of binaries such as texinfo and ggrep).
even though it shouldn't, on my system it does this: checking libintl.h usability... yes checking libintl.h presence... yes checking for libintl.h... yes ... and that's why we have a patch in portage to fix it's NLS/libintl behaviour. I start to more and more believe in a stage3-like installer for prefix to avoid this horror.
I have now had the chance to try building Prefix Portage on Solaris/SPARC. It turns out that on Solaris/SPARC 'grep' is built with no problems by the bootstrap compiler (Code Listing 1.3). The bootstrap compiler version on my Solaris/SPARC system is 3.4.3. On Solaris/x86 I have been using a slightly higher version of GCC (3.4.5), however unsuccessfully. Just a thought ... would it be possible to write shellscript wrappers for grep/fgrep/egrep that understand (most of) the GNU grep options and calls Solaris grep with translated options? Such wrappers could then be inserted into $EPREFIX/tmp/usr/bin from the start and allow the bootstrapping process to run smoothly up to step 1.15 where GNU grep is properly emerged? Or is it just not feasible to do a precise emulation of GNU grep?
I'd like to avoid to do any extra work there. I believe prefix-launcher does a lot of efforts in that direction.
Seems reasonable. If bootstrapping on Solaris generally works nowadays it may be really hard to even reproduce this problem.
For what it's worth, this still seems to be an issue with x86 Solaris (5.11). If it's CANTFIX, does that mean we can't bootstrap Solaris? Guess I'll try installing ggrep as a workaround for now ...
can you give the exact error message?
