OpenBLAS @0.3.12: No rule to make target `../kernel/arm64/amin.S', needed by `samin_k.o'

[Gregory-Gelfond (Gregory Gelfond)]

sudo port install py38-matplotlib +cairo +ghostscript +latex +tkinter +webagg fails when attempting to build openblas:

--->  Fetching archive for OpenBLAS
--->  Attempting to fetch OpenBLAS-0.3.12_0+gccdevel+lapack.darwin_20.arm64.tbz2 from https://packages.macports.org/OpenBLAS
--->  Attempting to fetch OpenBLAS-0.3.12_0+gccdevel+lapack.darwin_20.arm64.tbz2 from https://ywg.ca.packages.macports.org/mirror/macports/packages/OpenBLAS/OpenBLAS
--->  Attempting to fetch OpenBLAS-0.3.12_0+gccdevel+lapack.darwin_20.arm64.tbz2 from https://mse.uk.packages.macports.org/OpenBLAS
--->  Building OpenBLAS
Error: Failed to build OpenBLAS: command execution failed
Error: See /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_math_OpenBLAS/OpenBLAS/main.log for details.
Error: Follow https://guide.macports.org/#project.tickets to report a bug.
Error: Processing of port py38-matplotlib failed

I've attached the main.log for reference.

[ryandesign (Ryan Carsten Schmidt)]

make[1]: *** No rule to make target `../kernel/arm64/amin.S', needed by `samin_k.o'.  Stop.

[radarhere (Andrew Murray)]

If it's helpful to anyone, I found that port install OpenBLAS +native works for me.

[michaelld (Michael Dickens)]

In ff03175e5e130a7bc661248822d5531f95e77dd1/macports-ports (master):

OpenBLAS: on ARM64 build as +native (​https://github.com/macports/macports-ports/pull/9661), see #61700

[jmroot (Joshua Root)]

Partly complete fix

[jmroot (Joshua Root)]

The attached patch should be a start at least. It should also be safe to commit as long as the set blas_arch "???" is not uncommented. At minimum, someone needs to figure out the correct arch name to use there, and of course test it.

[mascguy (Christopher Nielsen)]

It looks like OpenBLAS is being built with the following variants on ARM Macs, when implicitly installed as a dependency: +gccdevel+lapack+native. And that's causing oodles of buildbot failures.

Does anyone know why those specific variants are selected ONLY for an ARM build? Is ARM support only included in the development version of GCC at the moment...?

[mascguy (Christopher Nielsen)]

This may be causing a downstream issue, when generating Python bindings for opencv4:

issue:62744 - py39-opencv4 4.5.2: staging into destroot fails

[mascguy (Christopher Nielsen)]

Many changes have been made over the past few weeks, and OpenBLAS is now building on our buildbot.

Gregory, can you try reinstalling?

[NicosPavlov]

Also, based on other reports, OpenBLAS for M1 chips can be built with different targets: ​https://github.com/danielchalef/openblas-benchmark-m1. However, it should fall down to ARMV8 or VORTEX (they are equivalent in the current code). If someone is willing to test the fact of checking the architecture in the Portfile (see diff attached), that would be really helpful.

[michaelld (Michael Dickens)]

OpenBLAS is at 0.3.15 and about to be upgraded to 0.3.16. This issue is about 0.3.12, which is somewhat old now. I'm closing this as "fixed" since it probably has been in the interim. If anybody has this issue still, please update us with the new build log and we'll see what we can do.