Hi! elaexuo...@wilsonb.com skribis:
> More specifically, the package I have builds separate libraries for CPUs with > AVX, AVX2, and no AVX support. Since build-type isn't sufficiently specific to > distinguish such CPU features, I have, so far, opted to just build all three > libs and stuff them under <out>/lib/<foo>. > > My idea is to have the linker script check CPU features at runtime (by parsing > /proc/cpuinfo or something) and executing the binary with the parameters to > load the correct binary. > > Perhaps there is a better overall approach? I wrote about this topic in the past: https://hpc.guix.info/blog/2018/01/pre-built-binaries-vs-performance/ I you’re the upstream author, I recommend using one of the techniques given above to provide so-called “fat binaries” that contain several implementations of the performance-sensitive functions; the loader will pick the right implementation when the program starts. If you’re downstream… it depends on the specifics. The loader is also able to pick a .so from the right lib/ sub-directory depending on the micro-architecture. You can try: LD_DEBUG=files your program to see where the loader looks for shared libraries. HTH! Ludo’.
