On Wed, Apr 06, 2022 at 01:38:09PM +0200, Adam Borowski wrote: > On Sun, Apr 03, 2022 at 02:17:15PM +0300, Adrian Bunk wrote: > > On Fri, Mar 25, 2022 at 11:34:17PM +0100, Adam Borowski wrote: > > > * while a hard Depends: works for leafy packages, on a library it > > > disallows having alternate implementations that don't need the > > > library in question. Eg, libvectorscan5 blocks a program that > > > uses it from just checking the regexes one by one. > > > glibc 2.33 added a modernized version of the old hwcaps. > > If a package builds a library several times with different optimizations > > and installs them into the correct directories in the binary package, > > the dynamic linker will automatically select the fastest one supported > > by the hardware. > > > > SIMDe (or similar approaches) could be used to build variant(s) of the > > library that have compile-time emulation of SIMD instructions in the > > lower baseline builds of vectorscan. > > In this particular case, it'd probably be faster to use non-SIMD ways > instead of emulating them. This means two code paths, which particular > users may or may not want to do the effort to implement.
For supporting older baselines my priority would be functionality with minimal effort both for upstreams and Debian maintainers, not optimal performance on old hardware. > > For binaries, I have seen packages in the Debian Med (?) team that build > > several variants of a program and have a tiny wrapper program that chooses > > the correct one at startup. > > This may take substantial work to implement, which for typical Debian Med > packages is an utter waste of time. >... The proper approach would be to have the implenmentation in debhelper, so that the maintainer only has to declare which n different variants of the program to build on $architecture, and then everything including the wrapper is built by debhelper. I am not saying that I plan to implement it, but that's how I would design it to avoid the per-package work you are worried about. cu Adrian
