Date: Thu, 01 Jan 2026 09:38:04 -0300
On Thursday, 1 January 2026 05:38:37 Brasilia Standard Time Simon Schröder via
Std-Proposals wrote:
> Are you suggesting that Linux distributions should ship two libraries and do
> some magic to select the right one? I think it is quite obvious why Linux
> distributions choose backwards compatibility.
*I* am suggesting that. And glibc has such magic:
$ ldd /bin/openssl
linux-vdso.so.1 (0x00007f4b4c75c000)
libssl.so.3 => /lib64/glibc-hwcaps/x86-64-v3/libssl.so.3.5.3
(0x00007f4b4c50f000)
libcrypto.so.3 => /lib64/glibc-hwcaps/x86-64-v3/libcrypto.so.3.5.3
(0x00007f4b4be00000)
libc.so.6 => /lib64/libc.so.6 (0x00007f4b4ba00000)
libjitterentropy.so.3 => /lib64/libjitterentropy.so.3
(0x00007f4b4c502000)
libz.so.1 => /lib64/glibc-hwcaps/x86-64-v3/libz.so.1.3.1
(0x00007f4b4c4e8000)
/lib64/ld-linux-x86-64.so.2 (0x00007f4b4c75e000)
$ ldd /bin/kwrite | grep Qt6
libQt6Widgets.so.6 => /lib64/libQt6Widgets.so.6 (0x00007f0a06200000)
libQt6Gui.so.6 => /lib64/glibc-hwcaps/x86-64-v4/libQt6Gui.so.6.10.1
(0x00007f0a05600000)
libQt6Core.so.6 => /lib64/glibc-hwcaps/x86-64-v4/libQt6Core.so.6.10.1
(0x00007f0a04e00000)
libQt6Xml.so.6 => /lib64/libQt6Xml.so.6 (0x00007f0a06a1f000)
libQt6DBus.so.6 => /lib64/libQt6DBus.so.6 (0x00007f0a04332000)
libQt6Qml.so.6 => /lib64/libQt6Qml.so.6 (0x00007f0a02600000)
libQt6TextToSpeech.so.6 => /lib64/libQt6TextToSpeech.so.6
(0x00007f0a03c72000)
libQt6PrintSupport.so.6 => /lib64/libQt6PrintSupport.so.6
(0x00007f0a0253e000)
libQt6Network.so.6 => /lib64/libQt6Network.so.6 (0x00007f0a02000000)
libQt6Multimedia.so.6 => /lib64/libQt6Multimedia.so.6
(0x00007f0a00917000)
libQt6WaylandClient.so.6 => /lib64/glibc-hwcaps/x86-64-v4/
libQt6WaylandClient.so.6.10.1 (0x00007f0a000c9000)
The glibc-hwcaps feature is not meant for binary-incompatible builds.
[I don't know why my distro isn't shipping v3 glibc. libc itself doesn't
benefit much from the upgrade, making constant use of IFUNC. But libm does, in
spite of IFUNC]
Std-Proposals wrote:
> Are you suggesting that Linux distributions should ship two libraries and do
> some magic to select the right one? I think it is quite obvious why Linux
> distributions choose backwards compatibility.
*I* am suggesting that. And glibc has such magic:
$ ldd /bin/openssl
linux-vdso.so.1 (0x00007f4b4c75c000)
libssl.so.3 => /lib64/glibc-hwcaps/x86-64-v3/libssl.so.3.5.3
(0x00007f4b4c50f000)
libcrypto.so.3 => /lib64/glibc-hwcaps/x86-64-v3/libcrypto.so.3.5.3
(0x00007f4b4be00000)
libc.so.6 => /lib64/libc.so.6 (0x00007f4b4ba00000)
libjitterentropy.so.3 => /lib64/libjitterentropy.so.3
(0x00007f4b4c502000)
libz.so.1 => /lib64/glibc-hwcaps/x86-64-v3/libz.so.1.3.1
(0x00007f4b4c4e8000)
/lib64/ld-linux-x86-64.so.2 (0x00007f4b4c75e000)
$ ldd /bin/kwrite | grep Qt6
libQt6Widgets.so.6 => /lib64/libQt6Widgets.so.6 (0x00007f0a06200000)
libQt6Gui.so.6 => /lib64/glibc-hwcaps/x86-64-v4/libQt6Gui.so.6.10.1
(0x00007f0a05600000)
libQt6Core.so.6 => /lib64/glibc-hwcaps/x86-64-v4/libQt6Core.so.6.10.1
(0x00007f0a04e00000)
libQt6Xml.so.6 => /lib64/libQt6Xml.so.6 (0x00007f0a06a1f000)
libQt6DBus.so.6 => /lib64/libQt6DBus.so.6 (0x00007f0a04332000)
libQt6Qml.so.6 => /lib64/libQt6Qml.so.6 (0x00007f0a02600000)
libQt6TextToSpeech.so.6 => /lib64/libQt6TextToSpeech.so.6
(0x00007f0a03c72000)
libQt6PrintSupport.so.6 => /lib64/libQt6PrintSupport.so.6
(0x00007f0a0253e000)
libQt6Network.so.6 => /lib64/libQt6Network.so.6 (0x00007f0a02000000)
libQt6Multimedia.so.6 => /lib64/libQt6Multimedia.so.6
(0x00007f0a00917000)
libQt6WaylandClient.so.6 => /lib64/glibc-hwcaps/x86-64-v4/
libQt6WaylandClient.so.6.10.1 (0x00007f0a000c9000)
The glibc-hwcaps feature is not meant for binary-incompatible builds.
[I don't know why my distro isn't shipping v3 glibc. libc itself doesn't
benefit much from the upgrade, making constant use of IFUNC. But libm does, in
spite of IFUNC]
-- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Principal Engineer - Intel Data Center - Platform & Sys. Eng.
Received on 2026-01-01 12:38:14
