Summary: | sys-libs/pam-0.99.8.1-r1 gives "undefined symbol: LIBPAM_1.0" in sshd, vixie_cron | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Mike Hammill <michael> |
Component: | [OLD] Core system | Assignee: | MIPS Porters <mips> |
Status: | RESOLVED INVALID | ||
Severity: | normal | CC: | pam-bugs+disabled |
Priority: | High | ||
Version: | 2006.1 | ||
Hardware: | MIPS | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | readelf -s /lib/libpam.so.0 |
Description
Mike Hammill
2008-01-15 13:07:12 UTC
(In reply to comment #1) > http://www.gentoo.org/proj/en/base/pam/upgrade-0.99.xml > I know about the pam upgrade guide, and have had no problem using the new pam on x86, ppc, spark. I'll try again, though. I guess I had just done a cursory look for the baddies like pam_stack, pam_pwdb, pam_radius, and pam_timestamp as well as the qfile orphan check. Will go through to the nth degree trying to find out what could be changed from a newly installed pam 0.78-r5. Sorry for troubling you. Please attach `readelf -s /lib/libpam.so.0` output here... Created attachment 143640 [details]
readelf -s /lib/libpam.so.0
Sorry it took so long to get back to this. I can additionally report that I get the same error with pam-0.99.9.0 (I switched to unstable mips as the gentoo front page suggested.)
Looks like a problem with ld.so, mips team please advise. [I assume that both sshd and cron were restarted after upgrading pam] (In reply to comment #4) Damn, I see all version of SGI PAM before the non-functioning ones have been removed from portage. Seems a bit strange to remove old pams and just have new ones when bugs.gentoo.org has unresolved errors for the new versions. Personally, this gives me no way back. Hopefully I still have an old SGI with a working PAM on it I can quickpkg and bring over... :-( ...and yes, restarting of ssh, etc was done after the pam update. I know I have no room to complain since it took me so long to submit additional info. Don't mean to be bitchy. Anyway, thanks for looking into it. I will proceed with bringing over an old PAM from a working machine as a workaround. As far as ld goes, I'm using the newest binutils (see below). Not sure if ld.so means ld.so.cache generated by env-update, or something else. Just thought I would try to provide a bit of additional info in advance. livecd / # eix -I binutils [I] sys-devel/binutils Available versions: ~*2.15 2.16.1-r3 *2.16.91.0.6 2.17 2.17-r1 (~)2.17-r2 *2.17.50.0.12 *2.17.50.0.16 *2.17.50.0.17 (~)2.18 2.18-r1 **2.18.50.0.1 **2.18.50.0.2 **2.18.50.0.3 **2.18.50.0.4 {multislot multitarget nls test vanilla} Installed versions: 2.18-r1(23:04:40 01/13/08)(-multislot -multitarget nls -test -vanilla) Homepage: http://sources.redhat.com/binutils/ Description: Tools necessary to build programs [I] sys-devel/binutils-config Available versions: 1.8-r7 1.9-r4 Installed versions: 1.9-r4(22:00:46 12/29/07) Homepage: http://www.gentoo.org/ Description: Utility to change the binutils version being used Found 2 matches. ld.so is the dynamic loader, has nothing to do with binutils, it's part of glibc. As for the removal, I trust Kumba tested it so it seems not to be a problem on every setup. Plus 0.78 is likely more than vulnerable. You can make this bug closed. When building a new system from the current snapshot/stage3, apparently something bad happens when updating binutils. (I had this happen twice, and had to restore from an old version.) In any event, now perhaps because we're all supposed to use ~mips from now on, or something else which unfortunately I have no way of tracking down any longer, this error has disappeared. When it's fixed and there is no reason why, I believe it's generally referred to as "user error" :-) In any case, thanks for the tips. I couldn't have recovered without them. |