ld.so searches for libraries in /lib64 rather than /lib
- Found in: 1.19 on Debian lenny and Ubuntu gutsy on amd64
$ pola-run -B -e ls /bin/ls: error while loading shared libraries: libselinux.so.1: cannot open shared object file: No such file or directory $ pola-run --log -B -e ls ... #1: [r!] open: /lib64/libselinux.so.1, flags=0o0, mode=0o0: fail: No such file or directory ... $ ls -l /lib64 lrwxrwxrwx 1 root root 4 Jun 5 20:06 /lib64 -> /lib
On amd64, PlashGlibc's dynamic linker is looking for libraries in /lib64 and not in /lib. It doesn't find the libraries when -B is used because -B does not grant /lib64, only /lib.
PlashGlibc's ld.so's search behaviour might be different from Ubuntu/Debian's ld.so, which looks in /lib.
The problem goes away when the process can open /etc/ld.so.cache, because that tells ld.so to use the libraries from /lib rather than from /lib64:
$ pola-run -B -f /etc/ld.so.cache -e ls ...
/usr/lib64
The presence of dev packages such as libncurses5-dev is currently affecting whether Plash's unit tests pass. Bash depends on libncurses.so.5, and libncurses5-dev creates a symlink for this in /usr/lib, which is symlinked from /usr/lib64, which is where ld.so looks for and finds the shared library. When libncurses5-dev is not installed, ld.so looks in /lib64 and /usr/lib64 and fails to find the library. Installing build dependencies for gtk-powerbox-hook using pbuilder-satisfydepends causes libncurses5-dev to be uninstalled. This has been causing an odd situation where the tests pass when run from the ContinuousIntegration system, but not when I manually run them, since the latter usually happens after gtk-powerbox-hook has been built.
Solution 1
One solution is to have -B grant /lib64 as well as /lib. This wouldn't be harmful. It would have to cope with /lib64 not being there.
This should not be necessary for Debian but it would be useful for other systems.
Solution 2
Make PlashGlibc's ld.so consistent with that of the host system. It looks like we're inadvertently configuring glibc to use /lib64:
$ grep lib64 glibc-build/config.log
libc_cv_slibdir=/lib64
libc_cv_slibdir='/lib64'
libdir='${exec_prefix}/lib64'
Whereas the glibc Debian packaging overrides this: debian/sysdeps/amd64.mk