| Summary: | glib-perl-1.040 failes to build | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Geert Hauwaerts. <geert> |
| Component: | New packages | Assignee: | Gentoo Perl team <perl> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | ||
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Geert Hauwaerts.
2004-03-30 05:42:40 UTC
Can you do an emerge -p dev-perl/extutils-depends? From the glib-perl-1.040 ebuild:
>=dev-perl/extutils-depends-0.2*
i.e., the dep is listed, so now I need to figure out why it isn't being pulled in for you...
root@Liszt 07:00pm ~ # emerge -p dev-perl/extutils-depends These are the packages that I would merge, in order: Calculating dependencies ...done! [ebuild R ] dev-perl/extutils-depends-0.202 root@Liszt 07:05pm ~ # Any suggestions? Please re-emerge extutils-depends - I still say it sounds like portage (or perl) is confused as to whether this is actually installed. You didn't by chance upgrade perl in the recent past? (This would cause portage to think a package was installed, but could lead to confusion in perl itself if there were xs code involved). Already done that, still the same. Perhaps remerge perl? Try running:
perl -MExtUtils::Depends -e 'print $ExtUtils::Depends::VERSION, "\n", $INC{"ExtUtils/Depends.pm"}, "\n"'
then run:
locate ExtUtils/Depends.pm
In reply to comment 4, I've seen this sort of thing before - it happens when a module was installed manually, which means it went into the site_perl directory - which is scanned before vendor_perl where emerged modules get installed.
It's working fine, recompiling perl already did it. closing perl OP's last comments |