| Summary: | sys-libs/musl merged-usr cannot override libraries in /usr/lib via /etc/ld.so.conf.d/*.conf | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | ktoupt |
| Component: | Profiles | Assignee: | Anthony Basile <blueness> |
| Status: | UNCONFIRMED --- | ||
| Severity: | normal | CC: | ionen, ktoupt, lu_zero, musl, sam, toolchain |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| See Also: |
https://bugs.gentoo.org/show_bug.cgi?id=927691 https://bugs.gentoo.org/show_bug.cgi?id=923998 |
||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 690294, 928506 | ||
|
Description
ktoupt
2024-04-03 11:26:52 UTC
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 |
