Rikam si kam tento svet speje ... na reseni tohoto problemu a multi-arch knihoven by byla krasnym resenim FAT BINARY, jen by se verze x86_64 pridaly jako dalsi "architektura" (resp. nejaka subarchitektura, zjednodusuji, tech polozek na matchnuti by to chtelo asi vice). No a dynloader by si vybral nejlepsi moznost, takze by nic nebranilo aplikaci pro zakladni x86_64 aby se propojila s glibc ktere ma strcmp pres nejake AVX apod.
Fat Binary sa používajú keď chceš vytvoriť jednu binárku pre niekoľko rozdielných architektur, narp x86_64 a PowerPC, alebo x86_64 a ARM64. Pozri wiki: https://en.wikipedia.org/wiki/Fat_binary
Dynamic Scheduling ti zabezpečí, že bude jedna binarka jednej architektúry, ktorá bude mať v sebe "navyše" niekoľko ďalších "code paths" pre procesory, ktoré podporujú dané inštrukcie.
Presne tak ako vravíš. HWCAPS je novinka v GLIBC 2.33, ktorá vyšla 1. februára 2021, čiže predpokladám, že dosť málo ľudí o tejto feature vôbec vie.
vid link na phoronix: https://www.phoronix.com/scan.php?page=news_item&px=Glibc-2.33-Coming-HWCAPS
Fat binary umi libovolne kombinace, ale to neni podstatne, jak pise nekdo nize mechanismus jde pouzit i na ty verze x86_64. Nevyhoda je ze by se duplikovalo dost kodu
Uplne nejspravnejsi by myslim byla fat binary a neco na zpusob tech HWCAPS (jak pise zase nekdo dalsi vyse) kombinovany s individualni exportni tabulkou symbolu. To by zajistilo myslim nejmensi overhead.