Building on macOS
shradej1 opened this issue · 11 comments
Not sure if this is an issue with netlib-src or lapack (or me), but I'm unable to use this library on macOS. I have gcc / gfortran installed via homebrew, but the linker is unable to locate the libgfortran libraries. Running "cargo test" results in
error: linking with cc
failed: exit code: 1
= note: ld: library not found for -lgfortran
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Is this a supported platform?
I have the same problem. I think it arises when Homebrew is set up to install software in a custom directory without requiring the root privileges. In this case, the linker fails to find the needed libgfortran.dylib
. The workaround that I have been using is as follows:
ln -s "`brew --prefix`/Cellar/gcc/6.3.0_1/lib/gcc/6/libgfortran.dylib" ~/.rustup/toolchains/nightly-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/lib/
Adjust to reflect your versions of GCC and of the Rust toolchain.
If somebody knows a better way to make it work, please do let me know. Thanks!
Another solution can be seen in this script, which is how it works on Travis CI’s infrastructure:
#!/bin/bash
set -v
if [ "${TRAVIS_OS_NAME}" == "osx" ]; then
brew uninstall gcc49
while true; do
curl -L http://prdownloads.sourceforge.net/hpc/gcc-6.2-bin.tar.gz -o archive.tar.gz && break
done
mkdir root && tar -xzf archive.tar.gz -C root && sudo cp -R root/* /
fi
gfortran --version
Here I’m just installing GCC right into the root of the filesystem.
That I think got me part of the way there... now cargo test
fails in rustdoc --test
because
dyld: Symbol not found: _appleblas_i16gemm Referenced from: /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBNNS.dylib Expected in: /Users/.../rblas/target/debug/build/netlib-src-da4bf3f3106af0b5/out/lib/libBLAS.dylib in /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBNNS.dylib
I'm guessing the libBLAS.dylib being built by rust is getting picked up by the accelerate framework rather than its own libBLAS.dylib.
$ otool -L /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBNNS.dylib
/System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBNNS.dylib:
/System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBNNS.dylib (compatibility version 1.0.0, current version 1.0.0)
/System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libBLAS.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1238.0.0)
I should note that my lib.rs file contains a single line - extern crate netlib_src
Looks like this might be related to rust-lang/rust#25289?
This crate doesn’t have any bindings. What kind of code are you testing?
The link you gave seems to be broken.
Sorry, I updated the link. That's just it though - there's nothing to test. I list netlib-src as my only dependency in Cargo.toml, and lib.rs is a single line - "extern crate netlib_src;" I run cargo test
and get the above error.
You’re right. I also get the exact same error with Netlib’s implementation (netlib-src
). OpenBLAS’s one works just fine (openblas-src
). It used to work. Something has changed recently.
The interesting thing is that it works on Travis CI. Have a look here. All BLAS providers with respect to all Rust channels are green. Maybe it’s something related to the version of the OS used. I have Sierra, and I guess you too. Travis CI, on the other hand, has El Capitan.
I am running Sierra, although I tried on 10.11.6 (El Capitan) as well, and got a similar error.
dyld: Symbol not found: _cblas_dgemm
Referenced from: /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libvDSP.dylib
Expected in: /Users/shradej1/IdeaProjects/rblas/target/debug/build/netlib-src-da4bf3f3106af0b5/out/lib/libBLAS.dylib
in /System/Library/Frameworks/Accelerate.framework/Versions/A/Frameworks/vecLib.framework/Versions/A/libvDSP.dylib
Either way, I think your cargo ticket captures the problem. Definitely something different going on when cargo tries to run doc tests vs other tests. I'll keep an eye on that ticket. Thanks!
@shradej1, can you please try what’s on master? That error with _appleblas_i16gemm
should be gone. Thanks!
That did it. Thanks!