add support for iterative build of OpenBLAS with 64-bit integers

[jfgrimm]

(created using eb --new-pr)

[akesandgren]

I don't think adding _ilp64 suffix to the actual symbols is a good thing. Most codes I know of that does use ilp64 blas just assumes that the symbols are the same as usual.
I know I never did that when compiling it with 64bit integers way back and the codes that relied on it worked just fine that way

[jfgrimm]

@akesandgren good point, I've switched back to using LIBNAMESUFFIX

[migueldiascosta]

I agree it's simpler not to suffix the symbols, but otoh, numpy suggests using them to avoid clashes (https://numpy.org/devdocs/user/building.html#bit-blas-and-lapack), and SciPy says they actually need both (https://scipy.github.io/devdocs/dev/contributor/building.html#reference-for-build-options)...

Could we build all three variants?

[jfgrimm]

@migueldiascosta so, two 64bit iterations: one iteration with INTERFACE64=1 SYMBOLSUFFIX=64_ and one with INTERFACE64=1 LIBNAMESUFFIX=ilp64 ?

[migueldiascosta]

overriding the symbols is SYMBOLSUFFIX= (empty), I think

(edit: noticed now that I misread the above, so nevermind)

[akesandgren]

Conflict resolution needed.

Also, I think we should try to get both the plain 32bit int and the 64_ symbol suffix functions into the same libopenblas.(a|so) library in case that isn't already part of this change.

[bartoldeman]

@jfgrimm the _64 suffix isn't supported by OpenBLAS yet (it uses its own implementation of cblas that is not in sync with reference lapack). It will take some time for the ecosystem to catch up (FlexiBLAS and BLIS also)

the underscore is a little nasty as it was automatically added until this commit:
OpenMathLib/OpenBLAS@ca6b4961e4a5d280#diff-45268af9f7d4b41382cdaae2c9d9b4ff7e773f3cdfccff4a29b107cc955f4cd0

the Debian approach is probably better, see
https://salsa.debian.org/science-team/openblas/-/blob/master/debian/rules?ref_type=heads
basically, using LIBPREFIX=libopenblas or LIBPREFIX=libopenblas64 instead works with all recent OpenBLAS versions.
I can work on that.

[jfgrimm]

Yes, I was just looking at the debian recipe. We'll want to fix the .pc file to match as well

[bartoldeman]

done in
jfgrimm#5

[jfgrimm]

Test report by @jfgrimm

Overview of tested easyconfigs (in order)

• SUCCESS OpenBLAS-0.3.15-GCC-10.3.0.eb
• SUCCESS OpenBLAS-0.3.20-GCC-11.3.0.eb
• FAIL (build issue) OpenBLAS-0.3.23-GCC-12.3.0.eb (partial log available at https://gist.github.com/jfgrimm/f285f0506783946a5b0d6b841d8b6b6d)
• SUCCESS OpenBLAS-0.3.27-GCC-13.3.0.eb

Build succeeded for 3 out of 4 (4 easyconfigs in total)
node097.viking2.yor.alces.network - Linux Rocky Linux 8.9, x86_64, AMD EPYC 7643 48-Core Processor, Python 3.6.8
See https://gist.github.com/jfgrimm/c962f1c40abd55f6475d6be41c9fddd9 for a full test report.

[bartoldeman]

Test report by @bartoldeman

Overview of tested easyconfigs (in order)

• SUCCESS OpenBLAS-0.3.23-GCC-12.3.0.eb

Build succeeded for 1 out of 1 (1 easyconfigs in total)
login1.int.archimedes.c3.ca - Linux AlmaLinux 9.4 (Seafoam Ocelot), x86_64, Intel Xeon Processor (Skylake, IBRS) (cascadelake), Python 3.11.4
See https://gist.github.com/bartoldeman/8a93a10ea4838ff44977704ba346c62f for a full test report.

[bartoldeman]

Test report by @bartoldeman

Overview of tested easyconfigs (in order)

• SUCCESS OpenBLAS-0.3.27-GCC-13.3.0.eb

Build succeeded for 1 out of 1 (1 easyconfigs in total)
login1.int.archimedes.c3.ca - Linux AlmaLinux 9.4 (Seafoam Ocelot), x86_64, Intel Xeon Processor (Skylake, IBRS) (cascadelake), Python 3.11.4
See https://gist.github.com/bartoldeman/f63533c8bf71de7e4073a16957a157ce for a full test report.

[bartoldeman]

Test report by @bartoldeman

Overview of tested easyconfigs (in order)

• SUCCESS OpenBLAS-0.3.29-GCC-14.2.0.eb

Build succeeded for 1 out of 1 (1 easyconfigs in total)
login1.int.archimedes.c3.ca - Linux AlmaLinux 9.4 (Seafoam Ocelot), x86_64, Intel Xeon Processor (Skylake, IBRS) (cascadelake), Python 3.11.4
See https://gist.github.com/bartoldeman/5eb510c8bfbd594b394a3e1b11a22cd9 for a full test report.

[bartoldeman]

@jfgrimm not sure why your 0.3.23 failed..
we'll have to deal somehow with easyconfigs such as OpenBLAS-0.3.27-GCC-13.3.0-seq-iface64.eb. They compile fine, just generate some extra libraries where the libopenblas64.{so,a} libraries are identical to the libopenblas.{so,a} libraries, it looks backwards compatible to me.

[jfgrimm]

Could be some local hooks or something interfering... I'm on leave for a week starting today, so won't have an opportunity to check for a while.

[bartoldeman]

Test report by @bartoldeman

Overview of tested easyconfigs (in order)

• SUCCESS OpenBLAS-0.3.27-GCC-13.3.0-seq-iface64.eb

Build succeeded for 1 out of 1 (1 easyconfigs in total)
login1.int.archimedes.c3.ca - Linux AlmaLinux 9.4 (Seafoam Ocelot), x86_64, Intel Xeon Processor (Skylake, IBRS) (cascadelake), Python 3.11.4
See https://gist.github.com/bartoldeman/ca689f4d92decedd38ba389db0321d05 for a full test report.

[bartoldeman]

@jfgrimm any chance of rechecking your failed OpenBLAS-0.3.23-GCC-12.3.0.eb?

[jfgrimm]

@bartoldeman will retry in a sec

[jfgrimm]

Test report by @jfgrimm

Overview of tested easyconfigs (in order)

• SUCCESS OpenBLAS-0.3.23-GCC-12.3.0.eb

Build succeeded for 1 out of 1 (1 easyconfigs in total)
node034.viking2.yor.alces.network - Linux Rocky Linux 8.9, x86_64, AMD EPYC 7643 48-Core Processor, Python 3.6.8
See https://gist.github.com/jfgrimm/66cd3e9426642fdbbbbd434691199650 for a full test report.

[jfgrimm]

@bartoldeman success! also, fixed the minor merge conflict

[bartoldeman]

LGTM
merging now that EB 5.1 has been released