https://bugzilla.suse.com/show_bug.cgi?id=1223967 https://bugzilla.suse.com/show_bug.cgi?id=1223967#c15 --- Comment #15 from Atri Bhattacharya <badshah400@gmail.com> --- (In reply to Egbert Eich from comment #13)
(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.
This would mean that we still need a link from glibc-hwcaps/x86-64-v3/liblapack.so.3.12.0 to glibc-hwcaps/x86-64-v3/lapack/liblapack.so.3.12.0. Since this would have to be created from within baselibs.conf, there is the challenge how to obtain the .so version. This could be added to baselibs.conf if it was auto-generated from the main spec file.
Yes, we could do with lapack's baselibs.conf the same as we did with openblas's i.e. generate it dynamically from inside the specfile. I think we are slowly approaching the point where the baselibs.conf becomes difficult to read as well, though. What do we think about doing it the multibuild way instead, something like my trial in <https://build.opensuse.org/package/show/home:badshah400:lapackv3/lapack> goes? Looks more transparent, to me anyway. -- You are receiving this mail because: You are on the CC list for the bug.