merging python 2.4.6 in the 2.4 slot fails with the message: x86_64-pc-linux-gnu-ranlib libpython2.4.a x86_64-pc-linux-gnu-gcc -pthread -Wl,-O1 -Xlinker -export-dynamic -o python \ Modules/python.o \ -L. -lpython2.4 -lpthread -ldl -lutil -lm ./libpython2.4.so: undefined reference to `_PyParser_Grammar' collect2: ld returned 1 exit status make: *** [python] Error 1 * * ERROR: dev-lang/python-2.4.6 failed. * Call stack: * ebuild.sh, line 48: Called src_compile * environment, line 3609: Called die * The specific snippet of code: * emake || die "Parallel make failed" * The die message: * Parallel make failed Reproducible: Always Steps to Reproduce: 1.MAKEOPTS='-j4' emerge -av '=dev-lang/python-2.4.6'
Created attachment 192828 [details] emerge --info
Does it work with MAKEOPTS=""? And please use -O2 instead of -Os for testing.
python: maybe parallel build issue?
Got same when tried to update from 2.6.2-r1 to 2.6.4 MAKEOPTS='-j5', Intel(R) Core(TM)2 CPU T5600 @ 1.83GHz
(In reply to comment #3) > python: maybe parallel build issue? > Yes, all is OK with '-j1'
This happens with 2.6.5(-r2 to -r3 upgrade) too... -j6, with Paludis. I suppose it is caused randomly by paraller compilation. Solved by -j1.
Post the build log please...
Created attachment 241781 [details] Output of the build There you go.
ctypes module also isn't parallelization safe (just nailed that on first run with a make -j100... and no, my hardware isn't that good, just a good way to piss off parallelization issues). I'd really rather not see this get -j1'd... anyone feel like building up some patches?
(In reply to comment #9) > ctypes module also isn't parallelization safe _ctypes module is built by distutils and distutils doesn't support parallel building/installation.
*** Bug 333719 has been marked as a duplicate of this bug. ***
*** Bug 351514 has been marked as a duplicate of this bug. ***
This bug will be fixed in 2.7.2, 3.1.4 and 3.2.
I encountered this issue with -j6 on an Intel Core i7 2630QM, but an # emerge --resume immediately after the build error compiled the package correctly. Perhaps the error manifests randomly, depending on the compilation scheduling.
2.7.2, 3.1.4 and 3.2 are now in the tree, this issue should be fixed (thanks Arfrever).