Today, I tried to get a bit into the code of eselect. It seems that /usr/share/eselect/libs/multilib.bash is broken. There is a comment at the beginning saying: # list_libdirs PUBLIC # Returns a space separated list of libdirs available on this machine What the code actually does seems not right to me. It checks, whether the /lib, /lib32 or /lib64 directories are contained in /etc/ld.so.conf. At least in my ld.so.conf they are not present. (the ld.so.conf is automatically generated by env-update) ES_VALID_MULTILIB_DIRS="lib lib32 lib64" list_libdirs() { local dir libdirs libdirs="" for dir in ${ES_VALID_MULTILIB_DIRS} ; do if grep -q "^/${dir}\(\|/\)$" ${ROOT}/etc/ld.so.conf &> /dev/null ; then libdirs=( ${libdirs[@]} ${dir} ) fi done As none of the above directories is in ld.so.conf, multilib.bash considers ld.so.conf to be broken (which is wrong IMO). So the script takes what it can find in ${ROOT}/, removes preceding slashes and returns what remains. if [[ -z ${libdirs[@]} ]] ; then # Broken or non-existing ld.so.conf libdirs=( ${ROOT}/lib* ) libdirs=( ${libdirs[@]/\/lib/lib} ) fi echo "${libdirs[@]}" } btw: opengl.eselect assumes now that the returned directories are in /usr. Reproducible: Always
ld.so.conf is broken if it doesn't contain one of /lib, /lib64, and /lib32
In fact out of the 20 or so Gentoo machines (stable and ~arch) I have access to, none of them were missing at least a /lib entry. All the amd64 machines had /lib64 as well. Making this bug as invalid since the ld.so.conf was broken in this case.
I just checked the machine that was broken. The three paths /lib, /lib32 and /lib64 are now in /etc/env.d/04multilib and so they are in /etc/ld.so.conf, too. Must have been fixed with one of the many updates of the last twelve months.
