Arch Linux

Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#79940 - [lapack64] Symbols for the 64bit package should have a 64_ prefix

Attached to Project: Arch Linux
Opened by Yichao Yu (yuyichao) - Friday, 13 October 2023, 02:36 GMT
Last edited by Antonio Rojas (arojas) - Saturday, 14 October 2023, 19:27 GMT
Task Type Bug Report
Category Packages: Extra
Status Closed
Assigned To No-one
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No

Details

Description:

This issue is reported to lapack64 but is applicable to other related packages as well including blas64, cblas64, lapacke64 and openblas64.

Currently the 32bit and 64bit integer version of the package provide the libraries with different file names but the same symbol names despite the symbols being completely incompatible with each other. A suffix should be added to the symbol to distinguish between them so that libraries that uses different versions could be loaded without crashing.

Since libblastrampoline is added to the repo, a natural option is to add "64_" symbol suffix to the 64bit version. AFAICT this is also the convention followed by Fedora and it's a good idea to follow existing solution in this case.

Additional info:
* package version(s)
* config and/or log files etc.
* link to upstream bug report, if any

Steps to reproduce:
This task depends upon

Closed by  Antonio Rojas (arojas)
Saturday, 14 October 2023, 19:27 GMT
Reason for closing:  Upstream
Comment by Yichao Yu (yuyichao) - Friday, 13 October 2023, 02:39 GMT
And just to be clear, the symbol suffix on the actual library symbol would be 64_ but the fortran symbol suffix would be _64, i.e. for a fortran name `foo`, the 32bit function library/C symbol is `foo_` and the 64bit version would be `foo_64_`. libblastrampline already contain such symbols.
Comment by Antonio Rojas (arojas) - Friday, 13 October 2023, 06:49 GMT
This is something that needs to be sorted out upstream and coordinated between different providers, instead of each distro doing it their own (and possibly mutually incompatible) way.

For Netlib this is tracked in https://github.com/Reference-LAPACK/lapack/issues/666
Comment by Yichao Yu (yuyichao) - Friday, 13 October 2023, 21:07 GMT
OK. Good to know it's at least tracked upstream.

I do feel like only providing 64bit binary with conflicting symbol name isn't really a good position, even temporarily. Out of the few projects I've looked at, if they support 64bit interface then they would either expect a suffix or can be configured to do so. The current situation just make the 64bit binary a bit useless since if anything that uses the 32bit interface is loaded there's a high chance that something would crash...

I guess it's OK to wait to see if the upstream pick a direction. However, it also seems that there's no more progress on the upstream issue after the burst of comments a few months ago... It also won't be doing it in a mutually incompatible way either since Fedora is already doing it.
Comment by Yichao Yu (yuyichao) - Friday, 13 October 2023, 21:09 GMT
Also ref https://github.com/OpenMathLib/OpenBLAS/issues/3998#issuecomment-1762056277 . The openblas SYMBOLSUFFIX only works with make build system rather than the cmake one at the moment.
Comment by Antonio Rojas (arojas) - Saturday, 14 October 2023, 19:27 GMT
The only reason why we ship 64 bit integer versions is julia. By the time this was added, our openblas package didn't ship the lapack o cblas ABI so we needed to add the netlib 64 bit versions to work with openblas64.

Loading...