$EPREFIX/startprefix: line 37: 60903 Illegal instruction $SHELL -l Reproducible: Always Steps to Reproduce: 1. Follow the instructions http://www.gentoo.org/proj/en/gentoo-alt/prefix/bootstrap-macos.xml 2. run $EPREFIX/startprefix Actual Results: deepthought:~ root# /Gentoo/startprefix Entering Gentoo Prefix /Gentoo /Gentoo/startprefix: line 37: 61200 Illegal instruction $SHELL -l Leaving Gentoo Prefix with exit status 132 deepthought:~ root# Expected Results: Startprefix should set me in a shell like the discipton of the script says: Fabian Groffen <grobian@gentoo.org> -- 2007-03-10 # Enters the prefix environment by starting a login shell from the # prefix. The SHELL environment variable is elevated in order to make # applications that start login shells to work, such as `screen`. I have tried to bootstrap Gentoo-prefix in my as normal user first and than as root with the same result.
what is your shell, what is your platform/system
My shell is bash and my system is MAC OS X Version 10.6.5
does it also happen if you run this as non-root?
Yes. I first tried it as normal user in my home directory. (In reply to comment #3) > does it also happen if you run this as non-root? >
(In reply to comment #4) Yes. I first tried it as normal user in my home directory. > > (In reply to comment #3) > > does it also happen if you run this as non-root? > > >
I'm seeing this too on a fresh prefix install. I'm wondering if it is because I messed up CHOST. I did set it initially to x86_64-apple-darwin10 but then my shell got messed up and I forgot to reset it (or to add it to /etc/make.conf). I'll do emerge -e system now that it's set again to see if that helps.
ok, that's interesting. Can you be more specific in what way you messed it up?
(In reply to comment #7) > ok, that's interesting. Can you be more specific in what way you messed it up? I set CHOST per the instructions in the bootstrap guide (early on in the process). Somewhere (and I don't remember where) during the initial bootstrap my terminal connection got lost due to network issues. I reconnected and picked up where I left of, without setting CHOST again. Then I also didn't set it in /etc/make.conf and did 'emerge -e system'. B0rkage. The machine is now doing another 'emerge -e system' with the proper CHOST set, but it's at work and I can't monitor it. More tomorrow. I guess if that fails I'll do rm -rf /prefix and start over.
It's not CHOST. I recreated the prefix stuff from scratch today, without any CHOST setting, and I'm getting the same issue. Also, while doing the final 'emerge -e system' the sys-devel/binutils-apple-3.2.3-r2 build hangs at: i686-apple-darwin10-gcc -DI386 -Di486 -Di586 -Di686 -I.. -I../../include -I. -Wall -mdynamic-no-pic -DNeXT_MOD -DASLIBEXECDIR="/prefix/usr/lib/binutils/i686-apple-darwin10/3.2.3/" -O2 -pipe -march=nocona -ULTO_SUPPORT -c -MD \ -dependency-file ./xmalloc.d -o ./xmalloc.o ../xmalloc.c md -d -u ./Makedep ./xmalloc.d At this point the terminals become unresponsive, e.g. doing top or ps hangs indefinitely. We had an issue installing Xcode on this machine, so we are going to try re-installing that later today.
We've traced this back to incomplete installs of Xcode. We've now installed the package file directly instead of going to the normal installer, and with this the Xcode installation completed successfully instead of hanging at the final steps. Not sure what the actual difference was but our problems (both with bash and with compiling binutils) are gone now.
hmmm, interesting. I am examining the ability to work on a system without Xcode installed at the moment. Perhaps using csu would solve the problem as well.
I encountered the same problem. The behavior is a little odd. Running $EPREFIX/bin/bash works but $EPREFIX/bin/bash --login triggers the illegal instruction. I was using Xcode 3.2.5 and I had this problem even though my install completed successfully. After upgrading to Xcode 3.2.6 my next bootstrap was just fine.
I've heard suggestions that bash-4.2 solves this problem, but I don't have hard evidence
Sadly I spoke too soon. Although bash --login works, emerging zsh fails with an illegal instruction when invoking a bash script during make. If invoke the script from the command line it still fails, but the location of the failure in the script seems to change each time. If I run make from the command line then it doesn't exhibit the problem at all. Should I open a new bug for this zsh problem? Or is this really just a problem with a bad bash on OS X? Also Fabian's point in about bash 4.2 is correct. The 4.1 versions that I tried both caused Illegal Instruction errors when invoked with --login.
This was fixed in later bash versions.
