I haven't been able to compile perl after the initial install until a few minutes ago. Because of segfaults no matter what CFLAGS were used. Reproducible: Always Steps to Reproduce: 1.emerge perl 2. 3. Actual Results: The compile would segfault. Expected Results: Compile clean. I commented out the line in the perl-5.8.0-r10.ebuild that patches for the prelink. *Note that this line did not exist in the r9 ebuild. But it is mentioned in the Changelog for March or February. I have two other machines that have been updating nightly that have perl-r10 on them with compile dates of early April. The current ebuild has the timestamp of April 23. I belive it is possible that a revision level was missed. If this is true then if the prelink patch is in error, the next time a revision is released everybody may have the same problem.
I should mention that now python compiles cleanly on this fresh RC_4 install since commenting out the prelink patch in perl-r10. I have made a local ebuild for perl so I can continue the emerge -e on the new machine. Previously I had thought that the python compile issues were a different problem, each time I would compile python it would segfault later and later in the compile until it completed normally, but I now think this perl issue is connected.
The patch to prelink libpthread is not in -r9 because it was added in -r10. There have been a couple of silent revisions to the ebuild since then, which is why you see a newer timestamp. Silent revisions are done when there would be no benefit for people who have already successfully compiled the given version to recompile the software. Please check bug 20600, as this sounds to be a very similar problem. Also look at the CFLAGS that you used to compile glibc, as that includes libpthread. Perhaps there is an unavoidable conflict between the CFLAGS used to compile glibc and those used to compile perl.
Hmmm I don't know problem 20600 is so generic it could mean spilt coffee or a plugged drain. The only thing I know to tell you is that removing the patch for "prelink" allows it to run through. To tell you the truth I'm not very happy with the current status of "prelink" so if I could turn it off in my USE=" parameters I would but that won't help since there isn't any logic in the perl emerge to check for it.
Perhaps "prelink" was an unfortunate choice of words, because it has nothing to do with the feature of the same name described in http://www.gentoo.org/doc/en/prelink-howto.xml. When I say "prelink", I meant "link libpthread ahead of glibc, so that it is able to redefine symbols also defined in glibc". This is necessary for runtime signal handling to work properly. Since you say that sometimes compiles get a little farther along, is it possible that disabling that patch simply had a placebo effect? Have you encountered any other problems with applications that link with -lpthread?
I see what you mean. ref. # cd ${S}; epatch ${FILESDIR}/${P}-prelink-lpthread.patch No I recompiled the whole box (emerge -eDU world) the only things that gave me trouble were python, perl, avifile and openoffice. I thought that was very good out of 255 packages. Python would die later in the compile each time, three starts would usually complete it, avifile I just bypassed, perl got the patch commented out and openoffice is just plain PIA, I have another bug listed for it. If you think it is just an anomaly with my machine go ahead and close it since I have a workaround that works for me. Thanks!
*** This bug has been marked as a duplicate of 20600 ***