blas-lapack-rs / blas Goto Github PK

View Code? Open in Web Editor NEW

73.0 7.0 15.0 265 KB

Wrappers for BLAS (Fortran)

License: Other

Rust 82.12% Python 17.88%

linear-algebra science wrappers

blas's People

Contributors

Stargazers

Watchers

Forkers

emberian astraw masonium martyix termoshtt mattico tempbottle sebcrozet ramla-i stefan-k jonathanwoollett-light sarvex skblaz laurentmazare shivampr21

blas's Issues

safety - check slice sizes against size params

Currently if the user specifies invalid size parameters to blas routines, buffer overruns of the input slices may result within the foreign blas code.

It would be easy to check passed size arguments against slice sizes in many if not all of the wrapper blas functions prior to the foreign call. The performance cost should be negligible, much less than having even one additional row in an input matrix.

The checks would be only that the input buffer bounds are not overrun, it would not be a requirement that input sizes (or products of two of them) exactly match slice lengths, so full flexibility of the blas routines would be maintained.

Add thorough benchmarks

Port the BLAS benchmarks. Will be useful to judging the overhead added (should ideally be none), as well as comparing BLAS impementations.

blas and openblas-sys link against different versions of gfortran

Attempting to build blas on OSX High Sierra.
gcc 7 and 6 installed via homebrew.

If brew has 7 symlinked in, openblas-sys links correctly against gcc/7/libgfortran.4.dylib, but blas links against a non-existent gcc/6/libgfortran.3.dylib. I can't figure out where this is coming from.

If brew has gcc 6 symlinked in, things work as expected.

How to reproduce:

checkout blas
brew install gcc gcc6
brew switch gcc 7.X.X
cargo clean
cargo bench

Observed Behavior

dyld: Library not loaded: /usr/local/opt/gcc/lib/gcc/6/libgfortran.3.dylib

otool -L target/release/deps/blas-25ccd25572093ac2 shows that blas has linked against /usr/local/opt/gcc/lib/gcc/6/libgfortran.3.dylib (compatibility version 4.0.0, current version 4.0.0). I don't know where this path is coming from. This image does not exist.

otool -L target/release/build/openblas-src-93b86530c5caba86/out/opt/OpenBLAS/lib/libopenblas_haswellp-r0.2.20.dylib shows that openblas has correctly linked against /usr/local/opt/gcc/lib/gcc/7/libgfortran.4.dylib.

Workaround

brew switch gcc 6.X.X
cargo clean
cargo bench

In this case, both dylibs link against the gcc-6 libgfortran.3.dylib.

Fix poorly formated documentation

The following functions are poorly formated due to the poor formatting in the original code:

dsdot,
srotmg,
srotm,
drotmg, and
drotm.

The documentation script should be adjusted in order to account for those cases.

Add thorough test suite

Port over the BLAS test suite.

Messed up scalar arguments

Since the Fortran interface always takes pointers, the Python script could not distinguish between pointers to scalars and pointers to vectors and, hence, treaded every pointer as either &[T] or &mut [T].

Regards,
Ivan

Come up with a coherent design for the Matrix traits

It needs to expose all the functionality BLAS needs, but also carefully account for the rank. See if some nice wrapper can be made, especially around BandMatrix and PackedMatrix. Those probably shouldn't inherit from Matrix.

Incomplete example

A binary project like:
Cargo.toml:

blas = "0.22.0"

src/main.rs:

use blas::*;

let (m, n, k) = (2, 4, 3);
let a = vec![
    1.0, 4.0,
    2.0, 5.0,
    3.0, 6.0,
];
let b = vec![
    1.0, 5.0,  9.0,
    2.0, 6.0, 10.0,
    3.0, 7.0, 11.0,
    4.0, 8.0, 12.0,
];
let mut c = vec![
    2.0, 7.0,
    6.0, 2.0,
    0.0, 7.0,
    4.0, 2.0,
];

unsafe {
    dgemm(b'N', b'N', m, n, k, 1.0, &a, m, &b, k, 1.0, &mut c, m);
}

assert!(
    c == vec![
        40.0,  90.0,
        50.0, 100.0,
        50.0, 120.0,
        60.0, 130.0,
    ]
);

Does not work without unspecified prior work.

Steps required to run an example should be specified else it is not a very useful example.

Add C wrappers

As it’s been discussed here, the C interface should be supported by the crate.

Eliminate high-level wrappers

I started updating the package to use the Fortran bindings instead of the C ones, and now I tend to think that what we have right now in the root of the package should not be there. I think that the metal module should move to the root so that this package contains only minimalistic Rusty wrappers for BLAS. That code in the root is somewhat application specific; I, for example, have different requirements for storing and treating matrices and vectors. It started to deviate from BLAS. Moreover, the current root is in a deep work-in-progress state right now, and potential users just get confused; bare metal is sufficient in most cases.

@cmr, what do you think if I move metal to the root, and high-level wrappers will eventually become a separate package? Thanks!

Regards,
Ivan

Use system installed BLAS

Sorry if this has been answered somewhere else, but is it possible to use blas and blas-sys without using blas-src? E.g., using the system installed BLAS or one that I've already compiled?

Failure to compile example from Wiki

I'm having trouble compiling the example from the wiki. Given a Cargo.toml of:

[package]
name = "mytest"
version = "0.1.0"
edition = "2018"

[dependencies]
blas = "0.19"
openblas-src = "0.5"

and a main.rs of:

fn main() {
    use blas::*;

    let (m, n, k) = (2, 4, 3);
    let a = vec![
        1.0, 4.0,
        2.0, 5.0,
        3.0, 6.0,
    ];
    let b = vec![
        1.0, 5.0,  9.0,
        2.0, 6.0, 10.0,
        3.0, 7.0, 11.0,
        4.0, 8.0, 12.0,
    ];
    let mut c = vec![
        2.0, 7.0,
        6.0, 2.0,
        0.0, 7.0,
        4.0, 2.0,
    ];

    unsafe {
        dgemm(b'N', b'N', m, n, k, 1.0, &a, m, &b, k, 1.0, &mut c, m);
    }

    assert!(
        c == vec![
            40.0,  90.0,
            50.0, 100.0,
            50.0, 120.0,
            60.0, 130.0,
        ]
    );
}

I receive a compiler error of:


   Compiling mytest v0.1.0 (/path/to/somedir/)
error: linking with `cc` failed: exit code: 1
  |
  = note: "cc" "-Wl,--as-needed" "-Wl,-z,noexecstack" "-m64" "-L" "/home/someuser/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib" "/path/to/somedir/target/debug/deps/mytest-c25cf0aa53d2d5d1.13w5aln7qfvncvt4.rcgu.o" "/path/to/somedir/target/debug/deps/mytest-c25cf0aa53d2d5d1.14u0vpidl0sbmj0b.rcgu.o" "/path/to/somedir/target/debug/deps/mytest-c25cf0aa53d2d5d1.1c88w9g7t7n2s40l.rcgu.o" "/path/to/somedir/target/debug/deps/mytest-c25cf0aa53d2d5d1.1krajtmdy2yn378h.rcgu.o" "/path/to/somedir/target/debug/deps/mytest-c25cf0aa53d2d5d1.1qz396llvwat4zpy.rcgu.o" "/path/to/somedir/target/debug/deps/mytest-c25cf0aa53d2d5d1.1tad4rifk5jkfddw.rcgu.o" "/path/to/somedir/target/debug/deps/mytest-c25cf0aa53d2d5d1.21mgky5eb11hxae3.rcgu.o" "/path/to/somedir/target/debug/deps/mytest-c25cf0aa53d2d5d1.2hagi8yal5o30y1.rcgu.o" "/path/to/somedir/target/debug/deps/mytest-c25cf0aa53d2d5d1.2ktsn4br1k2smszs.rcgu.o" "/path/to/somedir/target/debug/deps/mytest-c25cf0aa53d2d5d1.2perbk8m0wb97cxo.rcgu.o" "/path/to/somedir/target/debug/deps/mytest-c25cf0aa53d2d5d1.2ubnhatjz686ehef.rcgu.o" "/path/to/somedir/target/debug/deps/mytest-c25cf0aa53d2d5d1.37xkbwbn91m8ubct.rcgu.o" "/path/to/somedir/target/debug/deps/mytest-c25cf0aa53d2d5d1.39ab1dod37ggxihr.rcgu.o" "/path/to/somedir/target/debug/deps/mytest-c25cf0aa53d2d5d1.3ahxxxsnylushd0a.rcgu.o" "/path/to/somedir/target/debug/deps/mytest-c25cf0aa53d2d5d1.3d4bhef1rcvdpgsb.rcgu.o" "/path/to/somedir/target/debug/deps/mytest-c25cf0aa53d2d5d1.3ewy9mbg9t5vffpv.rcgu.o" "/path/to/somedir/target/debug/deps/mytest-c25cf0aa53d2d5d1.3r6jvjkvsut4a89o.rcgu.o" "/path/to/somedir/target/debug/deps/mytest-c25cf0aa53d2d5d1.3toj37gza9k1y6u0.rcgu.o" "/path/to/somedir/target/debug/deps/mytest-c25cf0aa53d2d5d1.4182y0zotoic8e23.rcgu.o" "/path/to/somedir/target/debug/deps/mytest-c25cf0aa53d2d5d1.44pxkqpm25uzgq9h.rcgu.o" "/path/to/somedir/target/debug/deps/mytest-c25cf0aa53d2d5d1.4fmzgi3v7fq9gyoa.rcgu.o" "/path/to/somedir/target/debug/deps/mytest-c25cf0aa53d2d5d1.54tqyqmcztojjhq8.rcgu.o" "/path/to/somedir/target/debug/deps/mytest-c25cf0aa53d2d5d1.56xnjyiiiwmd666i.rcgu.o" "/path/to/somedir/target/debug/deps/mytest-c25cf0aa53d2d5d1.58cedehdxovh6kmo.rcgu.o" "/path/to/somedir/target/debug/deps/mytest-c25cf0aa53d2d5d1.awprjvw26g7l29h.rcgu.o" "/path/to/somedir/target/debug/deps/mytest-c25cf0aa53d2d5d1.bqyiwcm31ib37sz.rcgu.o" "/path/to/somedir/target/debug/deps/mytest-c25cf0aa53d2d5d1.jnn7qfowzc2ee4q.rcgu.o" "/path/to/somedir/target/debug/deps/mytest-c25cf0aa53d2d5d1.oo7bneinvm3yyac.rcgu.o" "/path/to/somedir/target/debug/deps/mytest-c25cf0aa53d2d5d1.w41aa5jadqop0an.rcgu.o" "-o" "/path/to/somedir/target/debug/deps/mytest-c25cf0aa53d2d5d1" "/path/to/somedir/target/debug/deps/mytest-c25cf0aa53d2d5d1.oulkxomifrbq6a0.rcgu.o" "-Wl,--gc-sections" "-pie" "-Wl,-zrelro" "-Wl,-znow" "-nodefaultlibs" "-L" "/path/to/somedir/target/debug/deps" "-L" "/path/to/somedir/target/debug/build/openblas-src-268ee3801b064ca1/out/opt/OpenBLAS/lib" "-L" "/home/someuser/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib" "-Wl,-Bstatic" "/path/to/somedir/target/debug/deps/libblas-643116a8da1a1f32.rlib" "/path/to/somedir/target/debug/deps/libnum_complex-305b1318b4d3efeb.rlib" "/path/to/somedir/target/debug/deps/libnum_traits-c14fcad4261d1c45.rlib" "/path/to/somedir/target/debug/deps/libblas_sys-51123d7b1471b1bb.rlib" "/path/to/somedir/target/debug/deps/liblibc-47d537f8e91fe919.rlib" "-Wl,--start-group" "/home/someuser/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libstd-4a76ff35a356aedf.rlib" "/home/someuser/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libpanic_unwind-e11c7b3b3225afe2.rlib" "/home/someuser/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libbacktrace-13217ede3d276f16.rlib" "/home/someuser/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libbacktrace_sys-621a9ee22da6caa1.rlib" "/home/someuser/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/librustc_demangle-546c844e8071bbeb.rlib" "/home/someuser/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libhashbrown-be9569e4d599746f.rlib" "/home/someuser/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/librustc_std_workspace_alloc-47d8845cef2a3bc5.rlib" "/home/someuser/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libunwind-017511bce73a530c.rlib" "/home/someuser/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcfg_if-be7979c57a08057b.rlib" "/home/someuser/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/liblibc-d6459c4f0817c67c.rlib" "/home/someuser/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/liballoc-580035dd98451925.rlib" "/home/someuser/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/librustc_std_workspace_core-aee5c24fff305dea.rlib" "/home/someuser/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcore-8a55a4098920125a.rlib" "-Wl,--end-group" "/home/someuser/.rustup/toolchains/stable-x86_64-unknown-linux-gnu/lib/rustlib/x86_64-unknown-linux-gnu/lib/libcompiler_builtins-9fc4b5be2ba5cc19.rlib" "-Wl,-Bdynamic" "-lutil" "-lutil" "-ldl" "-lrt" "-lpthread" "-lgcc_s" "-lc" "-lm" "-lrt" "-lpthread" "-lutil" "-lutil"
  = note: /usr/lib/gcc/x86_64-pc-linux-gnu/8.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: /path/to/somedir/target/debug/deps/mytest-c25cf0aa53d2d5d1.37xkbwbn91m8ubct.rcgu.o: in function `blas::dgemm':
          /home/someuser/.cargo/registry/src/github.com-1ecc6299db9ec823/blas-0.19.1/src/lib.rs:2124: undefined reference to `dgemm_'
          collect2: error: ld returned 1 exit status
          

error: aborting due to previous error

error: Could not compile `mytest`.

To learn more, run the command again with --verbose.

In case there's a question, libopenblas.so did compile successfully and the symbol dgemm_ is present:

$ nm -a libopenblas.so | grep dgemm_
0000000000098c20 T dgemm_
00000000002f2c00 T dgemm_beta
00000000002f0210 T dgemm_incopy
00000000002f05e0 T dgemm_itcopy
00000000002e9600 T dgemm_kernel
0000000000164310 T dgemm_nn
00000000001648b0 T dgemm_nt
00000000002f0aa0 T dgemm_oncopy
00000000002f1650 T dgemm_otcopy
0000000000d19188 D dgemm_p
0000000000d19168 D dgemm_q
0000000000d19148 D dgemm_r
000000000017c160 T dgemm_thread_nn
000000000017cf80 T dgemm_thread_nt
000000000017ddc0 T dgemm_thread_tn
000000000017ec00 T dgemm_thread_tt
0000000000164e30 T dgemm_tn
00000000001653e0 T dgemm_tt

Any idea of what's going on?

Complex is not `repr(C)`

The issue about complex is a bit tricky. In practice there is no problem at all; its memory layout is compatible with C complex, so using &num::Complex<f64> where a pointer to c complex is expected, is completely fine.

rust-num/num#79

However it is our common interest that the linked issue is resolved in some way.

Confusion regarding 0 and 1 based indexing

Not sure if this is the right place for this issue. I am using this crate in its latest version and link against a self-built OpenBLAS 0.2.19.

Consider the following piece of code:

use blas::c as cblas;
use blas::fortran as fblas;

#[test]
fn test_amax() {
    let idx_c = cblas::isamax(1, &[1.0], 1);
    let idx_f = fblas::isamax(1, &[1.0], 1) as i32;
    assert_eq!(idx_c, idx_f); // idx_x = 0 while idx_f = 1
}

The assertion will fail since idx_c and idx_f are not the same. It looks like the Fortran version returns 0 as an error value and 1-based indices while the C version returns 0 as an error value and 0-based indices (meaning than one can't differentiate between an error and a successful return value).
The documentation (OpenBLAS refers to the Intel MKL docs as a valid reference) is quite clear on the fact that the index should be 1-based though:

Returns the position of vector element that has the largest absolute value such that x[index-1] has the largest absolute value.
-- https://software.intel.com/en-us/mkl-developer-reference-c-cblas-i-amax

Add zrot

The zrot function seems to be missing.

https://www.netlib.org/lapack/explore-html/d1/d45/group__rot_gaac9d54e7408105ad6f4c810902e75b7a.html#gaac9d54e7408105ad6f4c810902e75b7a

Eliminate CBLAS

Calling through CBLAS and not the Fortran interfaces adds an unavoidable function call overhead that is completely unnecessary. Switch over to the Fortran interfaces.

Do not compile on MacOS 10.14.3, Apple LLVM version 10.0.0 (clang-1000.11.45.5)

I'm trying to compile gemm example from crate page and it gives me error:

error: linking with "cc" failed: exit code: 1

 = note: Undefined symbols for architecture x86_64:
            "_dgemm_", referenced from:
                blas::dgemm::hea1ad9439b9f3ae2 in hello_cargo-e34d1495f2dabfc9.47k295ih7vv0tck5.rcgu.o
          ld: symbol(s) not found for architecture x86_64
          clang: error: linker command failed with exit code 1 (use -v to see invocation)

Linker errors on example program

Hello,

I'm using this crate and the example program fails due to linker issues.

Suggestions?

Sorry, I'm fairly new to Rust.

Scalar arguments should really be T rather than &[T]

Some of the arguments should really be &T rather than &[T]:

pub unsafe fn zgemm(
    ...
    alpha: &[c64], 
    ...
    beta: &[c64], 
    ...
)

Problems with gnu toolchain on windows

I have this dependency:

blas = "0.18.1"

During building this simple program (no types used de facto in the program):

extern crate blas;
use blas::c::*;

I get these errors:

error: linking with `gcc` failed: exit code: 1
  |
  = note: "gcc" "-Wl,--enable-long-section-names" "-fno-use-linker-plugin" "-Wl,--nxcompat" "-nostdlib" "-m64" "C:\\Users\\steve\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\crt2.o" "C:\\Users\\steve\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\rsbegin.o" "-L" "C:\\Users\\steve\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib" "C:\\Users\\steve\\Dropbox\\Projects\\rpolysolve\\target\\debug\\deps\\rpolysolve-88ff07ef5c6657b1.0.o" "-o" "C:\\Users\\steve\\Dropbox\\Projects\\rpolysolve\\target\\debug\\deps\\rpolysolve-88ff07ef5c6657b1.exe" "-Wl,--gc-sections" "-nodefaultlibs" "-L" "C:\\Users\\steve\\Dropbox\\Projects\\rpolysolve\\target\\debug\\deps" "-L" "C:/Users/steve/Dropbox/Projects/rpolysolve/target/debug/build/openblas-src-d878051769a2d73f/out\\opt/OpenBLAS/lib" "-L" "C:\\Users\\steve\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib" "-Wl,-Bstatic" "C:\\Users\\steve\\Dropbox\\Projects\\rpolysolve\\target\\debug\\deps\\libblas-b4aae95537d012fb.rlib" "C:\\Users\\steve\\Dropbox\\Projects\\rpolysolve\\target\\debug\\deps\\libblas_sys-e0d39b2df28e83ce.rlib" "C:\\Users\\steve\\Dropbox\\Projects\\rpolysolve\\target\\debug\\deps\\libopenblas_src-f69049297a7464c8.rlib" "C:\\Users\\steve\\Dropbox\\Projects\\rpolysolve\\target\\debug\\deps\\libnum_complex-f6dcb9467a42a2a8.rlib" "C:\\Users\\steve\\Dropbox\\Projects\\rpolysolve\\target\\debug\\deps\\liblibc-c8ae433ae4a960ed.rlib" "C:\\Users\\steve\\Dropbox\\Projects\\rpolysolve\\target\\debug\\deps\\libnum_traits-f34085513d19d5a6.rlib" "C:\\Users\\steve\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\libstd-5a958d157a8d8d98.rlib" "C:\\Users\\steve\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\libpanic_unwind-14e8bb7ca07ebf2c.rlib" "C:\\Users\\steve\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\libunwind-a4bc20050f473f79.rlib" "C:\\Users\\steve\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\liblibc-892bd58ec617c3bd.rlib" "C:\\Users\\steve\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\librand-ce86047000b56785.rlib" "C:\\Users\\steve\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\libcollections-b8b9a576d130e244.rlib" "C:\\Users\\steve\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\liballoc-b9c9173c47c20c41.rlib" "C:\\Users\\steve\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\liballoc_system-141f235246f01712.rlib" "C:\\Users\\steve\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\libstd_unicode-9fbe5d3bbc85c563.rlib" "C:\\Users\\steve\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\libcore-3a6338503b91076c.rlib" "C:\\Users\\steve\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\libcompiler_builtins-e9e280acad4314a4.rlib" "-Wl,-Bdynamic" "-l" "gfortran" "-l" "openblas" "-l" "advapi32" "-l" "ws2_32" "-l" "userenv" "-l" "shell32" "-Wl,-Bstatic" "-l" "gcc_eh" "-l" "pthread" "-Wl,-Bdynamic" "-lmingwex" "-lmingw32" "-lgcc" "-lmsvcrt" "-luser32" "-lkernel32" "C:\\Users\\steve\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\rsend.o"
  = note: ld: cannot find -lgfortran
          C:/Users/steve/Dropbox/Projects/rpolysolve/target/debug/build/openblas-src-d878051769a2d73f/out\opt/OpenBLAS/lib/libopenblas.a: file not recognized: File format not recognized

My active toolchain is stable-x86_64-pc-windows-gnu. I want to keep it, because this is the only working approach for debug, which I've found (msvc toolchain doesn't allow to run dgb and thus debug in CLion).

What can I do? Are there any other connectors between rust and blas? More scpecially I need to call dsyev_. May be there are any other known stable methods of calculating real eigen values in rust?

link failure on Windows during cargo build

With a 64 bit mingw toolchain, attempt to build on Windows 10 is failing at link stage. The first signs of trouble in the output are messages such as:

ld.exe: i386 architecture of input file `../libopenblas_haswellp-r0.2.17.a(saxpy.obj)' is incompatible with i386:x86-64 output

(This is repeated for many many object files).

This same toolchain is able to successfully compile and link the latest openblas distribution obtained independently.

The toml contains:
blas = "0.*
and the command was:
cargo build

A shortened version of the output can be seen here .

(Until this is resolved, is there a way to have the blas crate use the openblas artifacts I was able to compile myself independently?)

Support for half/float16 (and bfloat16?)

Thanks for these great blas bindings, these are super convenient. Apologies if f16/bf16 support has been mentioned in the past, I haven't found any related issue.

Do you think it would be possible to have support for f16 support in this crate? mkl supports these (half/f16, bf16). The half crate provide nice types for f16/bf16 on the rust side so it would be nice to have some hgemm functions that would operate on these.
Happy to help in any way I can.

(for context we're working on some ML framework crate and it would be great to provide mkl as an efficient cpu backend)

Carefully audit the ranks passed, and especially the debug assertions.

I'm not sure if I was confused or what, but it seems most/all of the rank handling is somewhat incorrect.

Linking Error on MacOS (10.14.2)

When compiling on MacOS using openblas-src as the dependency for blas, I've been receiving the following errors:

ld: warning: ignoring file ../libopenblas_haswellp-r0.2.20.a, file was built for archive which is not the architecture being linked (x86_64): ../libopenblas_haswellp-r0.2.20.a Undefined symbols for architecture x86_64: "_caxpby_", referenced from: -exported_symbol[s_list] command line option

I've attempted to install openblas via homebrew as well as via the toml, but I do get the same error either way.

I then proceeded to attempt it with netlib-src, which resulted in:

ld: warning: ignoring file libVerifyFortran.a, file was built for archive which is not the architecture being linked (x86_64): libVerifyFortran.a Undefined symbols for architecture x86_64: "_VerifyFortran", referenced from:

It appears as if there is some general linking error with the library on the latest version on MacOS?