[Bug 1223783] New: Upgrade lapack to 3.12.0
![](https://seccdn.libravatar.org/avatar/a895f78a81a109471893519443e4d933.jpg?s=120&d=mm&r=g)
https://bugzilla.suse.com/show_bug.cgi?id=1223783 Bug ID: 1223783 Summary: Upgrade lapack to 3.12.0 Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Other Assignee: screening-team-bugs@suse.de Reporter: badshah400@gmail.com QA Contact: qa-bugs@suse.de Target Milestone: --- Found By: --- Blocker: --- Our lapack (at version 3.9.0) is pretty ancient at this point. We should consider bumping it straight to version 3.12.0 (released Nov 2023). Given the insane list of dependencies on lapack and its own rather insane list of patches used by Fedora [1], I thought of opening this tracking bug collecting the fallout that may or may not happen as a result of this upgrade (which I am starting work on, but seems more than a one-man job to be honest, so help welcome). The upcoming GCC14 breakage seems to be a good time to work on it since the latest version seems to fix this automatically. [1] https://src.fedoraproject.org/rpms/lapack/tree/rawhide -- You are receiving this mail because: You are on the CC list for the bug.
![](https://seccdn.libravatar.org/avatar/a895f78a81a109471893519443e4d933.jpg?s=120&d=mm&r=g)
https://bugzilla.suse.com/show_bug.cgi?id=1223783
https://bugzilla.suse.com/show_bug.cgi?id=1223783#c1
Atri Bhattacharya
![](https://seccdn.libravatar.org/avatar/a895f78a81a109471893519443e4d933.jpg?s=120&d=mm&r=g)
https://bugzilla.suse.com/show_bug.cgi?id=1223783
Atri Bhattacharya
![](https://seccdn.libravatar.org/avatar/a895f78a81a109471893519443e4d933.jpg?s=120&d=mm&r=g)
https://bugzilla.suse.com/show_bug.cgi?id=1223783
https://bugzilla.suse.com/show_bug.cgi?id=1223783#c3
--- Comment #3 from Atri Bhattacharya
I had briefly played with this idea when I looked at Lapack last, by I find cmake hard to debug, so I didn't pursue it. I'm fine if you do the conversion and make sure that it works ;)
Yes, the transition to cmake was one reason why I wanted to play it extra safe and test all packages dependent on lapack still build (and if they have %check sections, that they run) fine. And it looks ok so far (big batch of python-* packages to check but so far not issues building any of the packages — that were building against old lapack in science — in home:badshah400:lapack2023). I have also been testing put the update (installing, updating, removing, running tests) locally over the weekend.
Regarding update alternatives: They've given me a lot of grief. OBS staging is extremely picky about links that exist in one alternative but not the other. Unfortunately, you cannot run these tests yourself as there is not 'self-service' staging: you need to submit to Factory first and then let the staging managers check what breaks.
The only reason I went into lapack was to fix issues with update alternatives with respect to the openblas implementation. Presently, things are working and I hope I don't have to touch these pieces ever again (OBS staging is extremely picky about links that exist in one package but not the other).
Yes, I think your update-alternatives fixes were perfect and they are preserved in the updated package without any change (except for using _%{_arch} and dropping the user-defined %{a_x} macro but that can be easily switched back). The thing that I have worked on as part of this is to try and understand the baselibs.conf magic and I think I now have the baselibs.conf file in a state that produces working -32bit builds for x86_64 (have no way to test any other archs myself). I basically replicate your update-alternatives scriptlets in the baselibs.conf file with appropriate changes to the syntax. Tests installing, removing, and upgrading packages involving -32bit dependencies are in progress locally on my machine (so far look good). We will have to similarly fix the baselibs.conf for OpenBLAS too.
Regarding switching to 'liblaternatives': a. AFAIKT, libalternatives uses a binary wrapper (`alts`), thus it is for binaries only, not for libraries (@Adam?) b. In case my assessment in a. was wrong: If we do this change, we'd have to change OpenBLAS as well. Since libalternatives is not in SLE-15, we would have to introduce it there if we were to update OpenBLAS. This would in turn require an update to lapack - and possibly a code stream-`fork` (as we may not be able to introduce all required updates to all supported SLE service packs). Things would become much simpler if we kept the update-alternatives in place for the time being and postpone this change to when we know that no new version of OpenBLAS will be required for SLE-15 any more.
Even if we keep update-alternatives for the time being, for SLE (and Leap) we need to make sure that the way they are set up matches the present setting (names and location of links, which links we ship). This can be ensured by leaving update-alternatives in OpenBLAS untouched during this process and make sure we pass Factory staging.
Yes, I agree using libalternatives is not an option at this (or maybe at all) point for lapack. -- You are receiving this mail because: You are on the CC list for the bug.
![](https://seccdn.libravatar.org/avatar/a895f78a81a109471893519443e4d933.jpg?s=120&d=mm&r=g)
https://bugzilla.suse.com/show_bug.cgi?id=1223783
https://bugzilla.suse.com/show_bug.cgi?id=1223783#c5
--- Comment #5 from Atri Bhattacharya
![](https://seccdn.libravatar.org/avatar/a895f78a81a109471893519443e4d933.jpg?s=120&d=mm&r=g)
https://bugzilla.suse.com/show_bug.cgi?id=1223783
https://bugzilla.suse.com/show_bug.cgi?id=1223783#c6
--- Comment #6 from Atri Bhattacharya
Note one important step will be to make sure (at least for the shared libraries) that no symbols are removed. Ideally that should be the case for the static libraries as well - we've had multiple issues here in the past with lapack deprecating APIs and not building them by default when not specially asked.
I thought exactly the same, so we build with `cmake... -DBUILD_DEPRECATED=ON` to build all deprecated symbols into the shared libs, but I will go over the cmake files to see if there is any additional flags to be enabled for something this does not already take care of. Thanks for the feedback. -- You are receiving this mail because: You are on the CC list for the bug.
![](https://seccdn.libravatar.org/avatar/a895f78a81a109471893519443e4d933.jpg?s=120&d=mm&r=g)
https://bugzilla.suse.com/show_bug.cgi?id=1223783
https://bugzilla.suse.com/show_bug.cgi?id=1223783#c7
--- Comment #7 from Atri Bhattacharya
Note one important step will be to make sure (at least for the shared libraries) that no symbols are removed. Ideally that should be the case for the static libraries as well - we've had multiple issues here in the past with lapack deprecating APIs and not building them by default when not specially asked.
That might be OK for openSUSE but for old SLES codestreams we have to be careful. I'm not sure for SLE15 -> SLE16 compatibility but breaking the shared library ABI would be bad.
Could you suggest what SLE versions I should test the update against? I see that OBS allows me to add SLE-11-SP4, SLE-12-SP5, and SLE-15-SP1 through SP6 as build repositories to the project. -- You are receiving this mail because: You are on the CC list for the bug.
![](https://seccdn.libravatar.org/avatar/a895f78a81a109471893519443e4d933.jpg?s=120&d=mm&r=g)
https://bugzilla.suse.com/show_bug.cgi?id=1223783
https://bugzilla.suse.com/show_bug.cgi?id=1223783#c10
--- Comment #10 from Atri Bhattacharya
I think the best is to check SLE15 SP6 or simply what's in Leap 15.5 or 15.6 (I suppose we don't have any newer version in Backports). Note that on SLE15 lapack is built against the SLE-15:Update tree (thus against GA), but this shouldn't make a difference with respect to the ABI.
OK, good to know. I will be testing SLE:15-SP6 packages later as part of a sub-project. (In reply to Egbert Eich from comment #9)
@Atri: Indeed, Leap 15.5 / 15.6 have the same Lapack package as SLE. Moreover, at present, there is only one code stream of Lapack on Leap/SLE 15, this means that the version of Lapack is the same across all supported Leap/SLE versions.
OK, that helps reduce the testing needed, thanks.
As for baselibs.conf, you should be able to keep the existing one in Lapack as it appears to be sufficiently generic.
Actually, the baselibs.conf were not correct and led to 0-byte /usr/lib/libFOO.so.X files in the -32bit shared lib packages. This is discussed in more detail in bug 1207563. Basically this rendered the -32bit lib packages unusable. This is also fixed in my home branch by ensuring update-alternatives installs the right links (suffixed with _32bit to not conflict with non-biarch shared libs). Hope that clarifies the baselibs situation. -- You are receiving this mail because: You are on the CC list for the bug.
![](https://seccdn.libravatar.org/avatar/a895f78a81a109471893519443e4d933.jpg?s=120&d=mm&r=g)
https://bugzilla.suse.com/show_bug.cgi?id=1223783
https://bugzilla.suse.com/show_bug.cgi?id=1223783#c11
--- Comment #11 from Atri Bhattacharya
![](https://seccdn.libravatar.org/avatar/a895f78a81a109471893519443e4d933.jpg?s=120&d=mm&r=g)
https://bugzilla.suse.com/show_bug.cgi?id=1223783
https://bugzilla.suse.com/show_bug.cgi?id=1223783#c12
Atri Bhattacharya
![](https://seccdn.libravatar.org/avatar/a895f78a81a109471893519443e4d933.jpg?s=120&d=mm&r=g)
https://bugzilla.suse.com/show_bug.cgi?id=1223783
Martin Jambor
![](https://seccdn.libravatar.org/avatar/a895f78a81a109471893519443e4d933.jpg?s=120&d=mm&r=g)
https://bugzilla.suse.com/show_bug.cgi?id=1223783
https://bugzilla.suse.com/show_bug.cgi?id=1223783#c14
--- Comment #14 from Atri Bhattacharya
![](https://seccdn.libravatar.org/avatar/a895f78a81a109471893519443e4d933.jpg?s=120&d=mm&r=g)
https://bugzilla.suse.com/show_bug.cgi?id=1223783
https://bugzilla.suse.com/show_bug.cgi?id=1223783#c15
--- Comment #15 from Atri Bhattacharya
![](https://seccdn.libravatar.org/avatar/a895f78a81a109471893519443e4d933.jpg?s=120&d=mm&r=g)
https://bugzilla.suse.com/show_bug.cgi?id=1223783
https://bugzilla.suse.com/show_bug.cgi?id=1223783#c17
--- Comment #17 from Atri Bhattacharya
@Atri, sorry for not looking into this earlier, I've been side tracked by a huge security backport. I'll have a deeper look tomorrow.
No worries, take your time. I am just grateful for all the helpful suggestions, pointers, etc. you have already sent my way. -- You are receiving this mail because: You are on the CC list for the bug.
![](https://seccdn.libravatar.org/avatar/a895f78a81a109471893519443e4d933.jpg?s=120&d=mm&r=g)
https://bugzilla.suse.com/show_bug.cgi?id=1223783
https://bugzilla.suse.com/show_bug.cgi?id=1223783#c19
--- Comment #19 from Atri Bhattacharya
@Atri, thanks for doing all this work!
No problem, happy to lend a hand.
(In reply to Atri Bhattacharya from comment #14)
Perhaps difficult to work out given the structure of blas, cblas, lapack, and lapacke libraries, but it would be useful to look at installing the man files as part of the appropriate devel package instead of a separate -man package like we have now. The current status is the cleanest from the packaging point of view, but not the most end-user/dev friendly (lapack-man needs to be installed manually).
Wouldn't it work to make the man page package a dependency (ie Recommends:) of the -devel packages? This way, one can avoid installation if not required but it will be installed by default.
I think this would be better than the current status quo, but it would still entail recommending a bunch of lapack/cblas/lapacke man files for someone only interested in pure blas, for example. We could do this for now, as a stop-gap, until we can figure out a proper split of the man files sometime in the future.
Would you mind setting the package in your home to 'publish' so I'm actually able to install it?
Done, sorry for overlooking this earlier when I set up the repo. -- You are receiving this mail because: You are on the CC list for the bug.
![](https://seccdn.libravatar.org/avatar/a895f78a81a109471893519443e4d933.jpg?s=120&d=mm&r=g)
https://bugzilla.suse.com/show_bug.cgi?id=1223783
https://bugzilla.suse.com/show_bug.cgi?id=1223783#c22
--- Comment #22 from Atri Bhattacharya
I've noticed you're doing: %{_sysconfdir}/alternatives/libcblas.so.%{so_ver}_%{_arch} we used to do: %{_sysconfdir}/alternatives/libcblas.so.3%{?a_x} defining %a_x as: %if 0%{?suse_version} > 1500 %define a_x _%{_arch} %endif which was introduced with: https://build.opensuse.org/package/rdiff/science/lapack?linkrev=base&rev=35
Yes, I intentionally removed the conditionals and enabled _arch dependent link names to test baselibs generation for Leap. This change is not strictly needed — Leap does not build for the i586 arch anyway — and I can simply restore the previous a_x conditional macro if that is preferred. -- You are receiving this mail because: You are on the CC list for the bug.
![](https://seccdn.libravatar.org/avatar/a895f78a81a109471893519443e4d933.jpg?s=120&d=mm&r=g)
https://bugzilla.suse.com/show_bug.cgi?id=1223783
https://bugzilla.suse.com/show_bug.cgi?id=1223783#c23
--- Comment #23 from Atri Bhattacharya
![](https://seccdn.libravatar.org/avatar/a895f78a81a109471893519443e4d933.jpg?s=120&d=mm&r=g)
https://bugzilla.suse.com/show_bug.cgi?id=1223783
https://bugzilla.suse.com/show_bug.cgi?id=1223783#c25
--- Comment #25 from Atri Bhattacharya
Maybe, if you could define some macro:
%define somemacro _%{_arch} and replace '_%{_arch}' with by %{?somemacro} we can add the SLE/Leap15 handling back quickly if we notice issues. I leave the final name fpr 'somemacro' up to you.
Makes sense. Restored the conditionally defined %{a_x} macro in rev 34 (will supersede the open sr after your tests and a thumbs-up signal). -- You are receiving this mail because: You are on the CC list for the bug.
![](https://seccdn.libravatar.org/avatar/a895f78a81a109471893519443e4d933.jpg?s=120&d=mm&r=g)
https://bugzilla.suse.com/show_bug.cgi?id=1223783
https://bugzilla.suse.com/show_bug.cgi?id=1223783#c27
--- Comment #27 from Atri Bhattacharya
Thanks! It looks good, I've just done some very minimal tests but from these I believe we are Ok. Please create an SR. Let's see what staging has to say ;)
Thanks for testing. Here it is: https://build.opensuse.org/request/show/1180259 -- You are receiving this mail because: You are on the CC list for the bug.
![](https://seccdn.libravatar.org/avatar/a895f78a81a109471893519443e4d933.jpg?s=120&d=mm&r=g)
https://bugzilla.suse.com/show_bug.cgi?id=1223783
https://bugzilla.suse.com/show_bug.cgi?id=1223783#c28
Atri Bhattacharya
![](https://seccdn.libravatar.org/avatar/a895f78a81a109471893519443e4d933.jpg?s=120&d=mm&r=g)
https://bugzilla.suse.com/show_bug.cgi?id=1223783
https://bugzilla.suse.com/show_bug.cgi?id=1223783#c30
--- Comment #30 from Atri Bhattacharya
Thanks! I've pushed it to Factory: https://build.opensuse.org/request/show/1180289 I'll watch out for fallout today, I will be unavailable from tomorrow for the rest of the week. @Atri, could you have an eye on this while I'm gone, please?
I am on it, thanks for letting me know. -- You are receiving this mail because: You are on the CC list for the bug.
![](https://seccdn.libravatar.org/avatar/a895f78a81a109471893519443e4d933.jpg?s=120&d=mm&r=g)
https://bugzilla.suse.com/show_bug.cgi?id=1223783
https://bugzilla.suse.com/show_bug.cgi?id=1223783#c31
--- Comment #31 from Atri Bhattacharya
![](https://seccdn.libravatar.org/avatar/a895f78a81a109471893519443e4d933.jpg?s=120&d=mm&r=g)
https://bugzilla.suse.com/show_bug.cgi?id=1223783 Bug 1223783 depends on bug 1207563, which changed state. Bug 1207563 Summary: [openblas, lapack] Files for 'update alternatives' conflict with their 32-bit Counterparts https://bugzilla.suse.com/show_bug.cgi?id=1207563 What |Removed |Added ---------------------------------------------------------------------------- Status|IN_PROGRESS |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are on the CC list for the bug.
![](https://seccdn.libravatar.org/avatar/a895f78a81a109471893519443e4d933.jpg?s=120&d=mm&r=g)
https://bugzilla.suse.com/show_bug.cgi?id=1223783
https://bugzilla.suse.com/show_bug.cgi?id=1223783#c32
Atri Bhattacharya
participants (1)
-
bugzilla_noreply@suse.com