summaryrefslogtreecommitdiff
path: root/libexec/mail.local/locking.c
diff options
context:
space:
mode:
authorMark Kettenis <kettenis@cvs.openbsd.org>2024-01-14 09:39:04 +0000
committerMark Kettenis <kettenis@cvs.openbsd.org>2024-01-14 09:39:04 +0000
commit58bc31051a83b6f73ab5cedccc2d7c02cd9431ad (patch)
tree7132806122f86d6d3d0bb9b6336d4d4b944c0fb4 /libexec/mail.local/locking.c
parent6e2f4b48cec0dca9241d3a2f8ca63dcfe1c37df0 (diff)
Whenever we have a libc major bump, we run the risk that dependent shared
libraries will request a different (major) libc version from the one requested by the binary itself. For various reasons loading multiple libc versions is not a good idea, and since the introduction of msyscall(2) support, system calls will only work when called from one of the two loaded libcs. This really means that when we have a libc major bump, users must update all dynamic executables and shared libraries in the system. However, to ease this transition, change ld.so to only load the first libc version that we encounter (in a breadth first sense) and substitute that libc version for all further loads of libc, even if different versions are requested. This is done silently since I can't come up with a good warning message. In practice this means the libc version requested by the executable itself will be loaded. This means that shared libraries may fail to load if they use a symbol that has been removed. But given the constraints, this is the best that we can do. Even when we bump the libc major, the set of changes is typically small and most binaries and shared libraries will continue to run and allow the user to run pkg_add -u without any fallout. ok deraadt@, gkoehler@
Diffstat (limited to 'libexec/mail.local/locking.c')
0 files changed, 0 insertions, 0 deletions