blas-lapack-rs/netlib-src

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!