lapack @3.12.0_0+gfortran+openblas (and +accelerate) fails to build on MacOS 10.15 on x86_64

[Gandoon (Erik Hedlund)]

Trying to upgrade lapack +gfortran +openblas from @3.11.0_1 to 3.12.0_0 on a legacy system, MacOS 10.15.7. Last successful build was the one I am trying to upgrade from, built on 22 January 2024. See an excerpt from the attached log below.

. . .
:info:build   "_ztrsm_64_", referenced from:
:info:build       _cblas_ztrsm_64 in cblas_ztrsm.c.o
:info:build   "_ztrsv_64_", referenced from:
:info:build       _cblas_ztrsv_64 in cblas_ztrsv.c.o
:info:build ld: symbol(s) not found for architecture x86_64
:info:build clang: error: linker command failed with exit code 1 (use -v to see invocation)
:info:build make[2]: *** [lib/libcblas.3.12.0.dylib] Error 1
:info:build make[2]: Leaving directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_math_lapack/lapack/work/build'
:info:build make[1]: *** [CBLAS/src/CMakeFiles/cblas.dir/all] Error 2
:info:build make[1]: *** Waiting for unfinished jobs....
:info:build [  9%] Building Fortran object SRC/CMakeFiles/lapack.dir/slarfb.f.o
:info:build cd /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_math_lapack/lapack/work/build/SRC && /opt/local/bin/ccache /o
pt/local/bin/gfortran-mp-13 -Dlapack_EXPORTS  -pipe -Os -m64 -frecursive -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk -fPIC -c /opt/local/var/macports/build/_
opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_math_lapack/lapack/work/lapack-3.12.0/SRC/slarfb.f -o CMakeFiles/lapack.dir/slarfb.f.o
. . .
[ 47%] Built target lapack
make[1]: Leaving directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_math_lapack/lapack/work/build'
make: *** [all] Error 2
make: Leaving directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_math_lapack/lapack/work/build'
Command failed:  cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_math_lapack/lapack/work/build" && /usr/bin/make -j8 -w all VERBOSE=ON
Exit code: 2
Error: Failed to build lapack: command execution failed
Error: See /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_math_lapack/lapack/main.log for details.
Error: Follow https://guide.macports.org/#project.tickets if you believe there is a bug.

As can be seen, quite early on in the build process some symbols cannot be found. After that a bunch more is built successfully before the whole thing grinds to an unrecoverable halt.

Does anyone have a suggestion as for what to do here? It is not clear to me exactly what is the problem. I did also try using +accelerate instead, despite being uncertain whether this will negatively impact ports depending on lapack, but the error persists. I finally also tried using +gcc13 instead of +gfortranbut as expected, that was equally unsuccessful.

I noticed that there actually seems to be another, older active ticket that seems to be related, using +accelerate +gcc10: #67262 but with a similar error message (different symbol, but the same libcblas is involved).

[Gandoon (Erik Hedlund)]

Log from failed build of +openblas on MacOS 10.15

[Gandoon (Erik Hedlund)]

Log from failed build of +accelerate on MacOS 10.15

[Gandoon (Erik Hedlund)]

My recent edit of the ticket just clarified that it was not exactly the same issue as in #67262, but I expect it is similar enough to mention.

[Dave-Allured (Dave Allured)]

Eric, just for my information, did you try either lapack or lapack +gfortran, without either +accelerate or +openblas?

[Dave-Allured (Dave Allured)]

Erik, it looks like you did not use "-v" in your port install command. If this is correct, then would you please clean the port, then run the install command again with port -v install, then post the new main.log here? This will give me some more complete debug info. Thank you.

[jmroot (Joshua Root)]

The log should have the same information regardless of whether -v or -d are used. Those options just control whether the extra output is printed to the terminal as well.

[Gandoon (Erik Hedlund)]

Replying to Dave-Allured:

Eric, just for my information, did you try either lapack or lapack +gfortran, without either +accelerate or +openblas?

No, I did not. I have always had the +openblas enabled. It has never given me any trouble in the past. I could as an experiment try to build it without blas, but I am unsure if the rest of my system will work as intended in that case. I will return with the results once it has been tried.

As for the -voption mentioned, I always use it. Plus, as Joshua mentioned, it doesn't matter for the logs anyway. I am unsure of there is any -vv or similar option that gives extra verbose information that propagate to the build system and logs. But if there is, I have not used it.

[Gandoon (Erik Hedlund)]

Replying to Gandoon:

Replying to Dave-Allured:

Eric, just for my information, did you try either lapack or lapack +gfortran, without either +accelerate or +openblas?

No, I did not. I have always had the +openblas enabled. It has never given me any trouble in the past. I could as an experiment try to build it without blas, but I am unsure if the rest of my system will work as intended in that case. I will return with the results once it has been tried.

Ok, I have tried. It does build without +openblas or +accelerate. Thus, it seems to be an issue with the use of external blas libraries. Am I correct in that assessment?

So, my question now is: would this build without +openblas be detrimental with regards to performance? I do have OpenBLAS @0.3.25_6+gcc13+lapack built, as that is what is being used by, among several, Python and Octave. I expected OpenBLAS to require lapack +openblas in order to function correctly in that configuration. Maybe I am mistaken?

[Dave-Allured (Dave Allured)]

Erik and Joshua, thanks for straightening me out about -v. Also thanks for testing the generic lapack. That rules out some possible external problems with your Macports installation. My basic understanding is yes, the generic lapack will be significantly slower without either of the performance variants.

In LAPACK release notes I see that a new extended API with _64 suffix was added in 3.12.0. From your log files, 3.12.0 is now trying to build that extended API, and expecting a corresponding API from external CBLAS libraries. I think this explains these particular link failures. The messages match.

Unfortunately I am out of time for this right now. Someone needs to study LAPACK release notes, install docs, and help forums. Figure out how to either disable LAPACK building of the extended API, or else get that new extended API enabled in either the +openblas or +accelerate variants.

We could also consider reverting the 3.12.0 update until someone can get it working properly. You can revert to 3.11.0 in your own installation if you would like to try that. I can show you how to revert. Further thoughts, anyone?

[Gandoon (Erik Hedlund)]

Replying to Dave-Allured:

Erik and Joshua, thanks for straightening me out about -v. Also thanks for testing the generic lapack. That rules out some possible external problems with your Macports installation. My basic understanding is yes, the generic lapack will be significantly slower without either of the performance variants.

In LAPACK release notes I see that a new extended API with _64 suffix was added in 3.12.0. From your log files, 3.12.0 is now trying to build that extended API, and expecting a corresponding API from external CBLAS libraries. I think this explains these particular link failures. The messages match.

Unfortunately I am out of time for this right now. Someone needs to study LAPACK release notes, install docs, and help forums. Figure out how to either disable LAPACK building of the extended API, or else get that new extended API enabled in either the +openblas or +accelerate variants.

We could also consider reverting the 3.12.0 update until someone can get it working properly. You can revert to 3.11.0 in your own installation if you would like to try that. I can show you how to revert. Further thoughts, anyone?

Thanks, I will await any input then, unless I find a solution myself in the meantime.

As a reasonable user, I never removed the previous lapack @3.11.0_1+gfortran+openblas I had installed. So I will just activate that one for now. I have no linking errors with that, so that makes the most sense for the time being.

[tomio-arisaka (Tomio Arisaka)]

For example:

$ diff -u Portfile.orig Portfile
--- Portfile.orig	2024-01-30 12:32:00.000000000 +0900
+++ Portfile	2024-02-10 18:00:00.000000000 +0900
@@ -42,6 +42,7 @@
                     -DBUILD_SHARED_LIBS=ON \
                     -DCBLAS=ON \
                     -DLAPACKE=ON \
+                    -DBUILD_INDEX64_EXT_API=OFF \
                     -DCMAKE_INSTALL_INCLUDEDIR=${prefix}/include/${name} \
                     -DCMAKE_INSTALL_LIBDIR=${prefix}/lib/${name} \
                     -DCMAKE_INSTALL_RPATH=${prefix}/lib/${name} \

[Dave-Allured (Dave Allured)]

@tomio-arisaka, thank you for researching that. Pull request submitted:
​https://github.com/macports/macports-ports/pull/22635

[Dave-Allured (Dave Allured)]

In e3f88bd7e26ea01deba708429aace771cfc50a3f/macports-ports (master):

lapack: Fix builds with +accelerate +openblas

.

• Disable new extended Index-64 API which was introduced in LAPACK 3.12.0.
• Fixes #69295
• Maybe also fix 10.7 build, unrelated problem.

[Dave-Allured (Dave Allured)]

Erik, please give this new portfile a try when you get the chance. Just selfupdate, then try building the current version 3.12.0 with +accelerate or +openblas.

[Gandoon (Erik Hedlund)]

Replying to Dave-Allured:

Erik, please give this new portfile a try when you get the chance. Just selfupdate, then try building the current version 3.12.0 with +accelerate or +openblas.

I tried a few days back with the -DBUILD_INDEX64_EXT_API=OFF \ added to the portfile. And I now built lapack @3.12.0_1+gfortran+openblas and can confirm that both built as intended. As for working binaries, I cannot yet confirm, but I will trust it works for now as it has passed the tests.

Cheers!

(Oops, I pasted the wrong string earlier. Fixed now.)