On 2022/12/07 15:08:16 +0100, Dirk Müller wrote:
Hi Dan,
Am Mi., 7. Dez. 2022 um 14:08 Uhr schrieb Dan Čermák <dcermak@suse.de>:
That is not enough, because you'll end up with two rpms with exactly the same architecture and thereby potentially with the same NEVR. Any tooling that relies on rpm will not be able to distinguish these two packages and could pick the wrong one.
That is not a problem, if you restrict this to shared libraries. lets make an example with zstd (arbitrary choice).
you have zstd (/usr/bin/zstd) which requires a shared library libzstd.so.1. This is provided by libzstd1.x86_64 in opensuse (built for x86_64-v0). you can in addition to that provide a libzstd1-x86_64-v3.x86_64 package (so new name, same architecture) which contains the v3 optimized library in the hwcaps subdirectory. it does *not* provide anything by itself, but supplements libzstd1.x86_64.
in this setup, both packages are co-installable. the solver would only ever install the x86_64-v0 variant (so compatibility is always there) but if available, and --with-recommends is enabled, the -v3 package is installed in *addition*, and dynamically used automatically at runtime if hardware can do it.
so you have the following choices:
* really minimal (disk size) installations turn off --recommends, or remove the -v3 repo, and only get the x86_64-v0 (which is anyway code wise smaller, so if you want it, you get the smaller binary) * default installations get both libraries installed, so your hardware selects which variant gets picked. you get the better one if better hardware allows it. * you can not accidentally wreck your system by installing the -v3 variant only because it does not provide anything, so the solver would prevent you from doing something stupid.
This would be implementable via the existing build-baselibs mechanics which we use for building the -32bit/-64bit packages for years (by repacking them into a new name on the other architecture). it feels like this is relatively easy to implement.
Greetings, Dirk
AFAICR the ffmpeg/kodi people are able to build and load on demand optimized code for e.g. sse4 support. Also glibc/gcc has the opportunity to load/map optimized code at runtime for different CPUs all x86_64, at least I can remember on debugging a strange crash on an older AMD CPU within string operations which was not reproducable on Intel. I really wonder why this should not possible for v0 up to v3, maybe with an extended runtime linker. Werner -- "Having a smoking section in a restaurant is like having a peeing section in a swimming pool." -- Edward Burr