| Summary: | emerging openldap with USE="perl" fails with many undefined references | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Kevin <gentoo> |
| Component: | Current packages | Assignee: | Gentoo Perl team <perl> |
| Status: | RESOLVED NEEDINFO | ||
| Severity: | major | CC: | robbat2 |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | x86 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Kevin
2004-08-10 15:53:39 UTC
you broke your perl. 'emerge perl libperl' and i'm 99.9% sure it will go away. I had the same problem. Just updating libperl from 5.8.4 to 5.8.4-r1 solved the problem for me. Perhaps the package just needs a dependency to the newest libperl? I can't reproduce it myself with either version of perl-5.8.4{,-r1}, but I strongly suspect it's due to libperl not matching the perl version.
Kevin - any update on this? I ended up solving this problem, but it was a real pain to do so. IIRC, before trying this with openldap, I had upgraded my perl and in doing so added a USE flag for threads (that had not been present in my previous version of perl). This apparently resulted in having many perl packages installed in incorrect directory structures (the architecture-dependent directories) such that portage seemed to know that the packages were installed, and the perl paths were correct, but such that perl itself was not looking in the directories where the .pm files were actually located. I fixed it by re-emerging by hand every perl package that seemed to suffer from this architecture-dependent directory problem (first removing the package, then re-emerging it). I had to do this by hand for something like 100 perl packages. I would have thought that the libperl rebuild script that the ebuild announces that one must perform after upgrading perl would have accomplished all this for me, but it didn't. After upgrading perl, I actually ran that libperl rebuild script several times. In some of those runs, the script failed to complete (I think my iptables firewall was interfering), but I know it completed successfully at least 2 or 3 times. I would say that the real root of the problem I suffered is in the perl system of Gentoo, and probably only pops up when one changes from a no thread situation (that was how perl was originally installed on this box) to a threaded one (I added a second processor to the machine and that's why I started using threads) and then upgrade perl. I think this particular bug report can be closed, but someone may want to try to reproduce what I've described here after doing what I did with threads (first emerge an earlier version of perl with no thread USE flag present, then upgrade perl with the thread USE flag present, then try to emerge some package like openldap with the perl USE flag present). I'm guessing that if someone tries this, you'll be able to reproduce the problem I saw. you say you ran the script, but did you emerge libperl with USE=threads before running it? no response from user, closing. |