| Summary: | dev-lang/perl-5.8.8-r1 fails during install phase | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Sandro Bonazzola (RETIRED) <sanchan> |
| Component: | [OLD] Core system | Assignee: | Gentoo Perl team <perl> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | ||
| Priority: | High | ||
| Version: | 2006.0 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
portage log
libperl portage log |
||
|
Description
Sandro Bonazzola (RETIRED)
2006-03-30 10:46:59 UTC
Created attachment 83448 [details]
portage log
full portage log.
first stab is that it looks related to having threads enabled in perl (which as the ebuild says is at your own risk ;) taking a stab on an amd64 now, will let you know if i see anything. that last error you posted was actually just the last in a really long series I've tried every variation i can think of to dup this bug. I've tried starting with perl 5.8.7 and going to 5.8.8-r1 (all with ithreads btw); i've tried 5.8.8 -> 5.8.8-r1; i've tried 5.6.1 -> 5.8.7 -> 5.8.8-r1; i just can't get this to dup at all. I believe that the Perl_Gthr_key_ptr is definitely part of the ithreads symbol train, just don't understand why it would break out on you like that. can you please do an emerge -av libperl perl and paste that? I'd like to confirm that libperl has been build w/-r1 and ithreads. thanks, ~mcummings # emerge -av libperl perl These are the packages that would be merged, in order: Calculating dependencies... done! [ebuild R ] sys-devel/libperl-5.8.8-r1 USE="berkdb gdbm ithreads -debug" 0 kB [ebuild U ] dev-lang/perl-5.8.8-r1 [5.8.8] USE="berkdb gdbm ithreads -build -debug -doc -perlsuid" 0 kB (In reply to comment #3) > that. can you please do an emerge -av libperl perl and paste that? I'd like to > confirm that libperl has been build w/-r1 and ithreads. thanks, libperl has been built. it's perl that fails. I'll attach the libperl portage log. Created attachment 83834 [details]
libperl portage log
it seems that there's a depend error that is ignored. I don't know if this can help.
(In reply to comment #5) > libperl has been built. it's perl that fails. > I'll attach the libperl portage log. > actually, i just wanted to confirm libperl was also built with ithreads enabled :) I know i'm grasping, but would you mind disabling ccache for a test compile? Thanks, ~mcummings Have you always run this with the IT linguas? (curious) Sorry, should have explained my question. I noticed your errors all started up when attempting to load encoding and utf related tests/code Can't load '../lib/auto/PerlIO/encoding/encoding.so' for module PerlIO::encoding: ../lib/auto/PerlIO/encoding/encoding.so: undefined symbol: PerlIOBuf_open at ../lib/XSLoader.pm line 70. ...followed by a failure working with LOCALEs, followed by some symbol errors that look an awful lot like problems with libperl. (In reply to comment #9) > Have you always run this with the IT linguas? (curious) Yes. (In reply to comment #8) > I know i'm grasping, but would you mind disabling ccache for a test compile? > Thanks, Ok, with ccache disabled perl install fine. Maybe it could be a better thing rebuild libperl also. (In reply to comment #12) Ok, with ccache disabled perl install fine. Maybe it could be a better thing > rebuild libperl also. > Excellent! Sure beats the tangent I was prepared to go on to see if it was locale related :) Rebuild libperl would be wise, but if you can spare the cycles, i'd emerge -av libperl perl (since perl links against libperl, if there is anything screwy hidden in libperl it may still have affected the perl build), but that's just me being paranoid and making sure you know about it in case anything comes up later :) Going ahead and marking this fixed, but feel free to post (or even reopen) if you need to. |