| Summary: | Perl Segfaulting & version anomaly | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | David D. Huff Jr. <David.Huff> |
| Component: | [OLD] Core system | Assignee: | Robert Coie (RETIRED) <rac> |
| Status: | RESOLVED DUPLICATE | ||
| Severity: | normal | ||
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | x86 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
David D. Huff Jr.
2003-05-11 19:35:09 UTC
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!
|
