https://bugzilla.suse.com/show_bug.cgi?id=1223967 https://bugzilla.suse.com/show_bug.cgi?id=1223967#c14 --- Comment #14 from Richard Biener <rguenther@suse.com> --- (In reply to Atri Bhattacharya from comment #12)

(In reply to Egbert Eich from comment #9)

...

Actually, I believe I got baselibs.conf to work - at least the library part, haven't looked into the devel packages, yet

My understanding is that devel pkgs do not need to be administered the hwcaps treatment: What happens is that glibc automatically points the .so link in the devel pkg to the hwcaps dir `/usr/lib64/glibc-hwcaps/x86-64-v3/` target should both that dir and `/usr/lib64` contain the same name shared object even if the devel .so link target is to the latter. At least that is my reading of how it works with the zlib pkg anyway.

The link editor (/usr/bin/ld) processes the /usr/lib64/lib*.so link, hwcaps do not come into play at all here. The hwcaps variant is expected to have the same ABI as the "standard" variant so it doesn't make a difference which to use at link time. The dynamic loader upon execution of the linked program will then pick the hwcaps variant if the hardware matches. Note this is where it might be important that the hwcaps and non-hwcaps variant alternatives come from the same implementation unless the ABIs are 100% the same. So I think ideally the alternatives setup would have a link group and a single config to adjust. Not sure if it's done this way and whether it's possible at all if the group is split between two packages. -- You are receiving this mail because: You are on the CC list for the bug.