A while back, we made /lib64 a symbolic link to /usr/lib64:
https://fedoraproject.org/wiki/Features/UsrMove
Is it safe to assume that this symbolic link exists in all chroots? This includes the initial ramdisk, recovery environments, and chroots for confining services.
If we can assume that, we can tell glibc to stop searching for shared objects in /lib64 in addition to /usr/lib64. It will avoid an additional failing openat system call if the application calls dlopen with a shared object name that the system cannot find.
Thanks, Florian
On Thu, Nov 16, 2023 at 7:42 AM Florian Weimer fweimer@redhat.com wrote:
A while back, we made /lib64 a symbolic link to /usr/lib64:
https://fedoraproject.org/wiki/Features/UsrMove
Is it safe to assume that this symbolic link exists in all chroots? This includes the initial ramdisk, recovery environments, and chroots for confining services.
If we can assume that, we can tell glibc to stop searching for shared objects in /lib64 in addition to /usr/lib64. It will avoid an additional failing openat system call if the application calls dlopen with a shared object name that the system cannot find.
In all practical cases we have, you can make that assumption.
Is it safe to assume that this symbolic link [/lib64 -> usr/lib64] exists in all chroots? This includes the initial ramdisk, recovery environments, and chroots for confining services.
It is unsafe unless prominently documented in the places that are likely to be seen by affected developers, now and especially *in the future*: man glibc, info glibc, man chroot, info chroot, man docker, man virtmgr, etc. Such a change has aspects of being a System-Wide Change for Fedora. For instance, I have a recipe for an "embedded" Docker that will have to add the symlink.
On Thu, Nov 16, 2023 at 10:37 AM John Reiser jreiser@bitwagon.com wrote:
Is it safe to assume that this symbolic link [/lib64 -> usr/lib64] exists in all chroots? This includes the initial ramdisk, recovery environments, and chroots for confining services.
It is unsafe unless prominently documented in the places that are likely to be seen by affected developers, now and especially *in the future*: man glibc, info glibc, man chroot, info chroot, man docker, man virtmgr, etc. Such a change has aspects of being a System-Wide Change for Fedora. For instance, I have a recipe for an "embedded" Docker that will have to add the symlink.
Unless you are somehow excluding the "filesystem" package when building a Fedora rootfs (which is a required package, so it's quite hard to avoid), you are not going to be missing that symlink.
-
Florian Weimer -
John Reiser -
Neal Gompa