This is on a musl merged-usr system. Maybe glibc has a different linker where this is not a problem. The expectation is that the paths specified in /etc/ld.so.conf.d/*.conf override the normal paths since it appears first in /etc/ld.so.conf. However, there seems to be an implicit /lib at the very top, which, on a merged-usr system, is a link to /usr/lib, so libraries in /usr/lib will always be preferred over the ones specified in /etc/ld.so.con.d/*.conf. This is unexpected and partially the cause of bug 928506, where eselect {blas,lapack} is not working. A possible fix is to append /lib at the very end of /etc/ld.so.conf. Don't forget to run ldconfig if you are going to be manually adding that when testing.
I assume this is related to what happened in bug #927691 that made a mention of this file: $ cat /etc/ld-musl-x86_64.path /lib /usr/lib/gcc/x86_64-pc-linux-musl/13 /usr/lib /usr/local/lib /usr/lib/llvm/18/lib /usr/lib/llvm/17/lib And /lib being the problem. Not that I'm familiar with how musl handle things, haven't checked what makes/update that file but it's not updated on my recently merged musl (and merge was done after I had done the -e @world for 23.0, so didn't rebuild much post-merge).
(In reply to Ionen Wolkens from comment #1) > I assume this is related to what happened in bug #927691 that made a mention > of this file: > > $ cat /etc/ld-musl-x86_64.path > /lib > /usr/lib/gcc/x86_64-pc-linux-musl/13 > /usr/lib > /usr/local/lib > /usr/lib/llvm/18/lib > /usr/lib/llvm/17/lib > > And /lib being the problem. Not that I'm familiar with how musl handle > things, haven't checked what makes/update that file but it's not updated on > my recently merged musl (and merge was done after I had done the -e @world > for 23.0, so didn't rebuild much post-merge). I did not know about this file. Thanks. It looks like this file is updated after running ldconfig. ldconfig on musl system seems to be a bash script written by Gentoo Authors. The script reads /etc/ld.so.conf.d (and follows include /etc/ld.so.conf.d/*.conf) to add directories for the linker. In the function sanitize, it searches for /lib and /usr/lib and prepends them at the very top of the directories "list" if they were not "repeated", i.e., if they were not specified in ld.so.conf. In merge-usr, at least, /lib is not "repeated" by default in ld.so.conf, so it is, indeed, put at the very top, and /lib is a symlink to /usr/lib, so it bypasses overrides. Note how /lib (which is essentially /usr/lib) is above /usr/lib/{blas,lapack}/openblas, which was intended to override /usr/lib: $ cat /etc/ld.so.conf # ld.so.conf autogenerated by env-update; make all changes to # contents of /etc/env.d directory. include ld.so.conf.d/*.conf /usr/lib /usr/local/lib /usr/lib/rust/lib /usr/lib/llvm/18/lib /usr/lib/llvm/17/lib /usr/lib/octave/8.3.0 $ ldconfig Updating links is not implemented. $ cat /etc/ld-musl-x86_64.path /lib /usr/lib/gcc/x86_64-pc-linux-musl/13 /usr/lib/blas/openblas /usr/lib/lapack/openblas /usr/lib /usr/local/lib /usr/lib/rust/lib /usr/lib/llvm/18/lib /usr/lib/llvm/17/lib /usr/lib/octave/8.3.0 Now, if I specify /lib anywhere in ld.so.conf (or in the include), it is not prepended at the very top and the /usr/lib/{blas,lapack}/openblas overrides work: $ cat /etc/ld.so.conf # ld.so.conf autogenerated by env-update; make all changes to # contents of /etc/env.d directory. include ld.so.conf.d/*.conf /usr/lib /lib /usr/local/lib /usr/lib/rust/lib /usr/lib/llvm/18/lib /usr/lib/llvm/17/lib /usr/lib/octave/8.3.0 $ ldconfig Updating links is not implemented. $ cat /etc/ld-musl-x86_64.path /usr/lib/gcc/x86_64-pc-linux-musl/13 /usr/lib/blas/openblas /usr/lib/lapack/openblas /usr/lib /lib /usr/local/lib /usr/lib/rust/lib /usr/lib/llvm/18/lib /usr/lib/llvm/17/lib /usr/lib/octave/8.3.0 I don't know what the proper solution would be. Possible solutions I see: - Update ldconfig to be fine with missing /lib in merge-usr - Update ldconfig to append instead of prepend - Just add /lib in /etc/ld.so.conf somewhere Interestingly, I cannot figure out which package ldconfig is coming from; `qfile $(which ldconfig)` does not show anything.
(In reply to ktoupt from comment #2) > Interestingly, I cannot figure out which package ldconfig is coming > from; `qfile $(which ldconfig)` does not show anything. That's an unfortunate quirk of merge-usr and ebuilds that still install through the symlink, aka if it installed to /sbin/ldconfig then this is the path that's recorded in /var/db/pkg # qfile -v /sbin/ldconfig sys-libs/musl-1.2.4-r1: /sbin/ldconfig (on a related-note, ldconfig is regularly ran by env-update with each emerge invocation)
Also, musl's ldconfig seems to be some ..thing that we have in files/ldconfig.in-r3 -- so it's probably due to be fixed. Haven't really looked at it.
This is not an issue on glibc systems as far as I can tell.
(In reply to Ionen Wolkens from comment #4) > Also, musl's ldconfig seems to be some ..thing that we have in > files/ldconfig.in-r3 -- so it's probably due to be fixed. Haven't really > looked at it. Unsurprisingly, it's due to[1]: sanitize() { local drs=$@ repeated "${EPREFIX}/lib" ${drs} || drs="${EPREFIX}/lib ${drs}" repeated "${EPREFIX}/usr/lib" ${drs} || drs="${EPREFIX}/usr/lib ${drs}" echo ${drs} } Dropping the first line no longer adds /lib. Seems to be a fallback for when ld.so.conf did not exist which (always) adds /lib and /usr/lib while avoiding repeating them. Suppose one could either modify with USE=-split-usr or check if /lib == /usr/lib, not that I plan to look at this myself. [1] https://gitweb.gentoo.org/repo/gentoo.git/tree/sys-libs/musl/files/ldconfig.in-r3?id=b02003640#n113
