If you have an AFS installation, logged in as root, and have /usr/afsws mounted in AFS and try to use find you will get an error because /usr/afsws/lib/pam_afs.so is not found. With AFS properly setup the AFS PAM library will be configured in PAM and hence it is not necessary to explicitly specify it for the findutils package. This will also cause any script using "find" to fail, for example slocate database rebuild. Reproducible: Always Steps to Reproduce: 1. Set afs USE flag in /etc/make.conf 2. Emerge findutils 3. Run a find command, e.g "find /tmp" Actual Results: error in loading shared libraries: /usr/afsws/lib/pam_afs.so.1: cannot open shared object file: No such file or directory Expected Results: work, ;)
Bug 19994 has a lot of history here; please review it
That bug regards to complications building findutils and was concluded on a configuration that appeared to work. However with findutils correctly built there is the runtime problem described above and I can currently think of only two ways to resolve. 1) statically link findutils against pam_afs in order to resolve "pam_get_item", etc, linking errors. 2) re-code the afs logic to dynamically load pam_afs when the "-fstype afs" is specified on the command line. Actually a more simple question, why is pam_afs being linked to? In order to use PAM the PAM library should be linked to not a specific implementation. Changing the following line appears to work fine: --- findutils-4.1.20-r1.ebuild 2004-09-20 10:56:33.000000000 -0400 +++ findutils-4.1.20-r1.ebuild.original 2004-09-20 10:56:06.000000000 -0400 @@ -47,7 +47,7 @@ if use afs && use x86; then append-flags -I/usr/afsws/include append-ldflags -lpam - export LIBS="-lpam" + export LIBS="/usr/afsws/lib/pam_afs.so.1 -lpam" fi export CPPFLAGS="${CXXFLAGS}" use static && append-ldflags -static
Been running with findutils linked only to pam for a while and everything looks good. Hopefully someone can point out why pam_afs was explicitly linked.
*** Bug 102159 has been marked as a duplicate of this bug. ***
Taken from bug #102717 (for which the reporting incentives are both probable miscompilation of findutils and a change in library location for the new openafs ebuild, so it's related but I don't consider it a DUP): -- quote -- It seems very weird to me that a pam module has to be linked to recognize a filesystem. After trying to link without, it seems to me that the only missing symbol is "pioctl". This symbol is also defined in libafsauthent.so, another library installed by the openafs ebuild. For the moment, this library is incomplete (unresolved symbols) in stable ebuilds, and the unstable ebuilds (proposed in bug #100837) fix this for all archs except for amd64 (in the pipeline). I would therefore recommend keeping the current added libraries, but I wanted to state this for the record anyway. Might be a good idea to change this later. -- quote -- As for the dynamic loading of pam_afs.so.1 when necessary, I believe the afs-specific code is automatically triggered, not only when you explicitly specific -fstype afs. I don't think the solution is applicable anymore anyway, because the new openafs ebuild (1.2.13, 1.3.85, still in testing) have moved everything into FHS locations, so afs installed on the root filesystem. Of course you still have the option to use afs binaries on the /afs filesystem by simply not installing the openafs ebuild, but I don't feel we should support linking with a library on a network drive if there's an alternative. But in the end, as mentioned in bug #102717, it doesn't matter for this bug (if you reduce it to the question "how can I make find work the same way even when /usr/afsws/lib/pam_afs.so is not there?"), because the afs USE-flag currently doesn't even trigger the afs-specific code, so both the extra include path and the added libraries could just be left out without any side effect.
Fixed in 4.2.23.
