-
Notifications
You must be signed in to change notification settings - Fork 1.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make error if gfortran installed on Apple M1 machine #3032
Comments
Could you supply build log? The line before libm error does not require it. record like with a command |
Please try adding a line with |
There is no libSystem.dylib in /usr/lib.
|
I do not know much about the M1/OSX environment but these issues did not come up in earlier issue tickets, e.g. #2804 . |
Me too. I think it's because ld failed to find the math library. |
That should be possible to work around by adding the entry in test/Makefile and probably ctest/Makefile as well (though it still surprises me that this would come up only now) |
That's because they haven't used gfortran. |
Hmm. Still should not preclude building OpenBLAS itself - unfortunately I do not have M1 hardware and as far as I know none of the usual CI services offers it yet. (The libSystem.dylib issue affects "only" NumPy, or does it stop the OpenBLAS build as well ?) |
It's only for OpenBLAS. I even don't know why numpy needs OpenBLAS. |
IIRC you could configure numpy to link to Apple's Accelerate or to the unoptimized "netlib" reference LAPACK and BLAS for matrix/vector functions. (Though with the reference implementation you would be likely to hit the same gfortran issues). Are you building on the M1 system itself, or cross-compiling for it on an Intel-based host ? |
Just to clarify, do you run into the "missing libsystem.dylib" after fixing the Makefiles for the original libm problem, or where does this error come up ? |
No cross-compiling, native build. |
|
Around line 260 of test/Makefile you should have a line that starts with |
possibly needs to end up behind the |
Of course there is no libm. I don't know the SDK. It's strange the system is lack of libraries. |
|
It is in /usr/lib/system, probably |
Hm, strange. Somehow "it" thinks it is cross-compiling, but that should not break anything, only keep it from running the tests. And "it" already noticed the dependency on libm and put that in FEXTRALIB. |
How to install the SDK? I have not installed the SDK. |
|
|
Your link seems to be a build based on the one I mentioned, but if you look at unresolved issue 12 there fxcoudert/gfortran-for-macOS#12 it appears to describe the same problem. |
What do you get when compiling a simple hello world fortran program with |
|
It looks like gfortran was compiled with |
|
|
OpenBLAS build complete. (BLAS CBLAS LAPACK LAPACKE) OS ... Darwin "make PREFIX=/your_installation_path/ install". (or set PREFIX in Makefile.rule and run make install. install_name_tool -id /new/absolute/path/to/libopenblas_armv8p-r0.3.12.dev.dylib libopenblas_armv8p-r0.3.12.dev.dylib To install the library, you can run "make PREFIX=/path/to/your/installation install". |
It appears that gfortran has a somewhat-well-known issue in that it hard-codes the SDK path that was used to build it, which results in it falling flat on its face ("ld: library not found for -lm" is especially popular) if the version of the installed SDK does not match exactly. While I have never encountered this personally, it appears to affect at least our Monterey CI machine(s). Work around this by explicitly setting the SDKROOT to the appropriate path. (It appears we already do this for Bazel itself, but the macOS wheel builds need it set when we build dependencies, particularly MUMPS.) See also: OpenMathLib/OpenBLAS#3032 (comment).
It appears that gfortran has a somewhat-well-known issue in that it hard-codes the SDK path that was used to build it, which results in it falling flat on its face ("ld: library not found for -lm" is especially popular) if the version of the installed SDK does not match exactly. While I have never encountered this personally, it appears to affect at least our Monterey CI machine(s). Work around this by explicitly setting the SDKROOT to the appropriate path. (It appears we already do this for Bazel itself, but the macOS wheel builds need it set when we build dependencies, particularly MUMPS.) See also: OpenMathLib/OpenBLAS#3032 (comment).
Numpy needs OpenBLAS for building.
make
The text was updated successfully, but these errors were encountered: