I used a stage1 of 1.4_rc1 and it bootstrapped fine but then I got to the emerge system step and it failed on the very first package which is dev-python/python-fchksum-1.6.1 (there is a -r1 of this package but it's broken too) The problem is pretty much how it compiles the files.. gcc -DNDEBUG -march=i386 -mcpu=i386 -O3 -pipe -fPIC -I/usr/include/python2.2 -c md5.c -o build/temp.linux-i686-2.2/md5.o -march=pentium3 -O3 -pipe -mmmx -msse -fomit-frame-pointer -fforce-addr -falign-functions=4 -fexpensive-optimizations -fprefetch-loop-arrays -ffast-math -funroll-loops -foptimize-sibling-calls Is how it compiled on mine which lead to the following failure... md5.c: In function `md5_process_block': md5.c:439: internal error: Floating point exception Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://www.gnu.org/software/gcc/bugs.html> for instructions. error: command 'gcc' failed with exit status 1 As you probably noticed... the duplicated CFLAGS in the compile step... The 2nd set are the ones I have specified in my /etc/make.conf and have worked 100% ever since I've started using gcc-3.x which was in like May. So I asked drobbins to show me his compile step and this was it... gcc -DNDEBUG -march=athlon-tbird -O3 -pipe -fPIC -I/usr/include/python2.2 -c sum.c -o build/temp.linux-i686-2.2/sum.o -march=athlon-xp -funroll-loops -ffast-math -fexpensive-optimizations -m3dnow -msse -O3 -pipe As you can see he has 2 CFLAGS as well. I quickly noticed he had "athlon-tbird" while I had "i386" as the -march. I built from stage1 and he built from a stage3. So we assumed that the build was recycling the CFLAGS that python was built with for the stage and adding your own custom CFLAGS. So I set my /etc/make.conf CFLAGS to "" and I got gcc -DNDEBUG -march=i386 -mcpu=i386 -O3 -pipe -fPIC -I/usr/include/python2.2 -c md5.c -o build/temp.linux-i686-2.2/md5.o and the build was successful. Now obviously I don't to build my system with -march=i386 because then I'd have Debian.... so this is a problem... Now the problem lies in setup.py that comes with the sources of the package... That's what does the install. In version 1.6.1 of the ebuild we call python setup.py in src_compile() but there has been a eclass created that does this called "distutils" and this eclass is used in version 1.6.1-r1 but -r1 is masked. setup.py is the file that looks up the CFLAGS that Python was built with and sets them for the build and then ebuild adds your CFLAGS as well causing the problem. More to follow as I investigate first... I'd say this blocks the 1.4 release...
Ok... The original flags are pulled in from /usr/lib/python2.2/config/Makefile from a variable called OPT I have a couple methods to "fix" this, One: change the eclass to modify the Makefile every time... Two: change the python ebuild to kill all but the -NDEBUG OPT flag. One is a hack. It requires a non-sandbox edit of python's files, but has the benefit of not requiring a new set of stage1 tarballs. Two most definately requires a new set of stage1's. Since you have to have a clean python Makefile so that modules like fchksum will build. commited #2 as python-2.2.1-r4 masked.
stage1-x86-1.4_rc1-20020908-1208.tar.bz2 is being uploaded to the well known location while i type this.
this bug is releated to the python-*-r3 problem. the new stages are using python-*-rX, X>3 and i had no feedback that the problem still exists. in fact, every x86-stage on the mirrors has been built with python-*-r4 now, so it has proven to work quite a few times. so suggest this bug gets a timeout of some days, abd if no additional SOS shows up, we'll close it...
Well it was only a stage1 issue. I know for a fact that python -r4 fixes the problem. So I would say close out the bug.
