https://bugzilla.suse.com/show_bug.cgi?id=1223967 https://bugzilla.suse.com/show_bug.cgi?id=1223967#c2 Atri Bhattacharya <badshah400@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dleuenberger@suse.com --- Comment #2 from Atri Bhattacharya <badshah400@gmail.com> --- Dominique, would you please have a look (in your own time, no hurry). Thanks in advance. -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1223967 https://bugzilla.suse.com/show_bug.cgi?id=1223967#c4 --- Comment #4 from Atri Bhattacharya <badshah400@gmail.com> --- (In reply to Richard Biener from comment #3)

Hmm, but the dynamic loader relies on the shared library to be present in /usr/lib64/hwcaps/x86-64-v3/ (IIRC). So to work the alternatives link would need to be present there, pointing to the actual hwcaps library in /usr/lib64/blas/hwcaps/x86-64-v3/... (or another directory or a changed library name).

So I don't see how the generic hwcaps mechanism can be made work for the case of lapack. To me it seems the library copying would need to be done manually in lapack and only the multibuild part of the hwcaps mechanism preserved?

I see, thanks for the explanation.

That said, IMO having "alternatives" for shared libraries is a red herring... (but yeah, I understand why we have it, but then there's nothing wrong with Conflicts and multiple providers of liblapack.so.3)

Alternatively, is there a way to directly generate the -v3 tuned libs using a multibuild flavour specifically for this? I mean, we could give using the right flags to generate the v3 libs, move them to the appropriate location and package them as part of a package manually named to liblapack-x86_64-v3 or similar. However, I do not know what the macro does in step-by-step detail. -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1223967 https://bugzilla.suse.com/show_bug.cgi?id=1223967#c7 --- Comment #7 from Atri Bhattacharya <badshah400@gmail.com> --- So, what do we think: <https://build.opensuse.org/package/show/home:badshah400:lapackv3/lapack>

~> cat _multibuild <multibuild> <package>static</package> <package>x86-64-v3</package> </multibuild>

~> ls -1 *x86-64-v3*.rpm libblas3-x86-64-v3-3.12.0-97.1.x86_64.rpm libcblas3-x86-64-v3-3.12.0-97.1.x86_64.rpm liblapack3-x86-64-v3-3.12.0-97.1.x86_64.rpm liblapacke3-x86-64-v3-3.12.0-97.1.x86_64.rpm libtmglib3-x86-64-v3-3.12.0-97.1.x86_64.rpm

~> rpm -qvlp ./libblas3-x86-64-v3-3.12.0-97.1.x86_64.rpm ---------- 1 root root 0 May 5 02:25 /etc/alternatives/libblas.so.3-x86-64-v3_x86_64 drwxr-xr-x 2 root root 0 May 5 02:25 /usr/lib64/glibc-hwcaps/x86-64-v3/blas lrwxrwxrwx 1 root root 17 May 5 02:25 /usr/lib64/glibc-hwcaps/x86-64-v3/blas/libblas.so.3 -> libblas.so.3.12.0 -rwxr-xr-x 1 root root 1050584 May 5 02:25 /usr/lib64/glibc-hwcaps/x86-64-v3/blas/libblas.so.3.12.0 lrwxrwxrwx 1 root root 37 May 5 02:25 /usr/lib64/glibc-hwcaps/x86-64-v3/libblas.so.3 -> /etc/alternatives/libblas.so.3_x86_64 drwxr-xr-x 2 root root 0 May 5 02:25 /usr/share/doc/packages/libblas3-x86-64-v3 -rw-r--r-- 1 root root 6175 May 5 02:25 /usr/share/doc/packages/libblas3-x86-64-v3/README.md drwxr-xr-x 2 root root 0 May 5 02:25 /usr/share/licenses/libblas3-x86-64-v3 -rw-r--r-- 1 root root 2266 May 5 02:25 /usr/share/licenses/libblas3-x86-64-v3/LICENSE

Most of the hwcaps related definitions are in the preamble. I tried to preserve the maintainability/readability of the specfile to the extent I think is possible. Suggestions welcome. -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1223967 https://bugzilla.suse.com/show_bug.cgi?id=1223967#c12 --- Comment #12 from Atri Bhattacharya <badshah400@gmail.com> --- (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. -- You are receiving this mail because: You are on the CC list for the bug.

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

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.

We should probably implement a main and slave alternatives setup anyway so that both libblas.so.* and liblapack.so.* come from the same implementation. At the moment, my understanding is that one could theoretically use blas from implementation A (say, openblas) while still using cblas and lapack from the implementation B (reference netlib library, for example). I do not know whether this kind of usage is advisable. -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1223967 https://bugzilla.suse.com/show_bug.cgi?id=1223967#c22 --- Comment #22 from Atri Bhattacharya <badshah400@gmail.com> --- (In reply to Atri Bhattacharya from comment #20)

Thanks Egbert, this works great. Checkout rev 35 in obs://home:badshah400:lapack2023/lapack, where I have enabled the -v3 libs. In the same project I have patched the `build` package to add the mkbaselibs commit referenced in the github issue to get this working.

This has now moved to a new project: https://build.opensuse.org/project/show/home:badshah400:lapack-hwcaps so that I can go ahead and submit the fix to boo#1223783 from the old (home:badshah400:lapack2023) project where I have reverted the hwcaps generation. Sorry for the confusion. -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1223967 https://bugzilla.suse.com/show_bug.cgi?id=1223967#c24 --- Comment #24 from Atri Bhattacharya <badshah400@gmail.com> --- (In reply to Egbert Eich from comment #23)

@Atri: the major issues I'm seeing with the approach in home:badshah400:lapackv3/lapack are lines in baselib.conf like this: postin "ln -sf /etc/alternatives/libblas.so.3_<targettype> /usr/%_lib/libblas.so.3" postin "/usr/sbin/update-alternatives --force --install /usr/%_lib/libblas.so.3 libblas.so.3_<targettype> /usr/%_lib/blas/libblas.so.3 50" postun "/usr/sbin/update-alternatives --remove libblas.so.3_<targettype> /usr/%_lib/blas/libblas.so.3"

%_lib is a standard define which expands to /usr/lib or /usr/lib64. It doesn't expand to /usr/lib64/glibc-hwcaps/<targettype>:

home:badshah400:lapack-hwcaps/lapack/binaries$ rpm -q --scripts -p libcblas3-x86-64-v3-3.12.0-1.1.x86_64.rpm warning: libcblas3-x86-64-v3-3.12.0-1.1.x86_64.rpm: Header V3 RSA/SHA256 Signature, key ID 4aeaf2b5: NOKEY postinstall scriptlet (using /bin/sh): /sbin/ldconfig ln -sf /etc/alternatives/libcblas.so.3_x86-64-v3 /usr/lib64/libcblas.so.3 /usr/sbin/update-alternatives --force --install /usr/lib64/libcblas.so.3 libcblas.so.3_x86-64-v3 /usr/lib64/blas/libcblas.so.3 50 preuninstall scriptlet (using /bin/sh): /usr/sbin/update-alternatives --remove libcblas.so.3_x86-64-v3 /usr/lib64/blas/libcblas.so.3

The only way to handle this I can think of would be to do something like this:

postin "ldconfig -n /usr/%_lib/glibc-hwcaps/<targettype>/blas" postin "case <targettype> in x86-64-v*) p=glibc-hwcaps/<targettype> ;; esac" postin "/usr/sbin/update-alternatives --force --install /usr/%_lib/$p/libblas.so.3 libblas.so.3_<targettype> /usr/%_\ lib/$p/blas/libblas.so.3 50" postun "case <targettype> in x86-64-v*) p=glibc-hwcaps/<targettype> ;; esac" postun "/usr/sbin/update-alternatives --remove libblas.so.3_<targettype> /usr/%_lib/$p/libblas.so.3"

Disclaimer: I haven't tested this.

The attempt in obs://home:badshah400:lapackv3/lapack is to generate the x86-64-v3 libs purely as a separate flavour, *without* the baselibs.conf coming into play at all in so far as these -v3 libs are concerned. Baselibs.conf is still used to produce 32-bit biarch packages for pure x86_64 in this case, but it simply does not matter for x86-64-v3 flavour since there aren't i586-v3 equivalents. But perhaps I misunderstand your question? -- You are receiving this mail because: You are on the CC list for the bug.

https://bugzilla.suse.com/show_bug.cgi?id=1223967 https://bugzilla.suse.com/show_bug.cgi?id=1223967#c27 --- Comment #27 from Atri Bhattacharya <badshah400@gmail.com> --- (In reply to Egbert Eich from comment #26)

(In reply to Atri Bhattacharya from comment #24)

...

The attempt in obs://home:badshah400:lapackv3/lapack is to generate the x86-64-v3 libs purely as a separate flavour, *without* the baselibs.conf coming into play at all in so far as these -v3 libs are concerned.

Baselibs.conf is still used to produce 32-bit biarch packages for pure x86_64 in this case, but it simply does not matter for x86-64-v3 flavour since there aren't i586-v3 equivalents.

But perhaps I misunderstand your question?

No, you don't. What confused me: you were using the %suse_build_hwcaps macro - which you have removed since.

Yes, this macro should not be used if we want to use flavours to manually produce the -v3 libs instead of their generation via baselibs.

The problem I see is: this macro is crafted to add the right 'magic' to the spec file (see https://en.opensuse.org/openSUSE: Packaging_Conventions_RPM_Macros#%{?suse_build_hwcaps_libs}). This magic is "to automatically set specific build targets and schedule the job on workers which match the intended buildconstraint". Unfortunately, one can only guess how this works.

My understanding is that it pretty much checks for the avx/avx2 instruction support on the build host's CPU. Similar to having a _constraint file that limits the build to the avx2 supporting CPUs:

~> cat _constraints <constraints> <hardware><cpu> <flag>sse3</flag> <flag>avx2</flag> </cpu></hardware> </constraints>

Without baselibs.conf, two arch flavors will be built: x86_64 and x86_x6_v3. So I would think if you want to use flavors, you'd need to add: #!BuildTarget: x86_64_v3-linux #!BuildConstraint: hardware:cpu:flag x86-64-v3 to the spec file in the -v3 flavor on x86_64.

Yes, this is true. I have been only trying this out on my local machine (which supports x86-64-v3) but for a final version for OBS, my plan is to include a _constraints file to do this as documented here (or, equivalently, add the comments to specfile as you have noted): <https://openbuildservice.org/help/manuals/obs-user-guide/cha.obs.build_constraints#id-1.5.10.16.8.6.3.3>

When using baselibs.conf for -v3, mkbaselibs will create a spec file which consumes these packages and 'repackages them into the main architecture'. You may need to do all this manually. I'm currently trying to figure out how all this works.

Same here: home:badshah400:lapackv3 is an early experiment about using flavours to generate the -v3 libs. Not (yet) ready for prime time :) Thanks for your reviews/advice. Side note: I also learnt that RPM natively supports generating actual x86_64_v3 arch packages since version 4.19.0 (i.e. already in Factory). Perhaps we can have a look at how it does so: <https://github.com/rpm-software-management/rpm/commit/cd46c1704ccd8eeb9b600729a0a1c8738b66b847> -- You are receiving this mail because: You are on the CC list for the bug.