When building the example code from the readme, using the crates lapack (0.16.0) and openblas-src (0.6.0), I receive the linker error: undefined reference to `dsyev_'

This occurs with and without the "system" feature in openblas-src. I mention that all the required crates build fine - it's just my crate with the example code that fails.

Looking at the linker call that cargo makes, it appears that -lopenblas is not added to the linker options (nor is -llapack, assuming openblas-src builds the bundled Lapack?), and if I manually run the linker with the same arguments that cargo does, but adding -lopenblas, linking succeeds.

I'm on Arch Linux using Rust 1.27.1

The definitions of *spevx had ifail as a &mut i32, but it should actually be a &mut [i32] since it returns the array of indices of eigenvectors that failed to converge. See netlib reference: http://www.netlib.org/lapack/explore-3.1.1-html/dspevx.f.html

................/lapack-0.8.1/src/lib.rs:8262: undefined reference to `dsyev_'

I'm just trying the example and am getting this linking error. I installed OpenBLAS from git, having it in my library path.

Any idea?

ggev has incorrect type. It is not a scalar function and this is related to https://github.com/blas-lapack-rs/lapacke/issues/2. I would like to fix this but having trouble on setting up. Could you explain the procedure for contribution. Thanks

I tried below command, ./bin/generate.py --sys lapack-sys

What is your opinion on having LAPACK Auxiliary Routines in the crate, i.e. those listed here: http://www.netlib.org/lapack/lawn41/node112.html ?

I was looking at _lassq right now, and noticed that it's not part of this crate. Is this intentional, or do you welcome PRs for this?

Hi,

I noticed that the interface to the ?geev() methods changed from having argument such as vl: &mut [f64] to vl: &mut f64 (e.g. compare earlier commit 61d32 to commit c4daf ). This seems to be a bug, as vl and vr are array inputs to these functions. I could hand-tune the fortran.py (and c.py) to fix the function calls for ?geev() myself and submit a PR, but I don't know the reasons for switching vl and vr and worry that I may break other functions.

Note that fixing this will require bumping the version as we'll be changing the API.

Hi,

It seems that the num crate is quite heavily used, with >100k downloads over all time and thousands in the past weeks alone. In comparison, the complex crate has less than 1.5k downloads over all time. Therefore it seems to me that num is the de-facto standard for complex numbers and another module is likely going to lead to unnecessary code bloat and casting.

Are there any compelling reasons to stick with complex rather than switching to num? I'm not aware of any, but neither have I looked particularly deeply at the issue. Otherwise, I would propose moving to the num create. If there are features missing from num, I suppose the devs would welcome implementation of those missing features.

Another point is that, because num defines their Complex type as a generic for type T, it would be easier to implement support for different types as suggested in #6.

/// A complex number in Cartesian form.
#[derive(PartialEq, Copy, Clone, Hash, Debug)]
#[cfg_attr(feature = "rustc-serialize", derive(RustcEncodable, RustcDecodable))]
pub struct Complex<T> {
    /// Real portion of the complex number
    pub re: T,
    /// Imaginary portion of the complex number
    pub im: T
}

Finally, for maintaining compatibility in client code that uses complex::c32 and complex::c64, the following functions or similar could be used to implement the relevant cast:

extern crate num;
extern crate complex;
use std::mem::transmute;

#[inline]
fn to_complex_c32(x: & mut [num::Complex<f32>]) -> & mut [complex::c32] {
    unsafe { transmute(x) }
}

#[inline]
fn to_complex_c64(x: & mut [num::Complex<f64>]) -> & mut [complex::c64] {
    unsafe { transmute(x) }
}

https://github.com/rust-num/num-complex/releases/tag/num-complex-0.4.0

• blas https://github.com/blas-lapack-rs/blas/pull/35
• cblas https://github.com/blas-lapack-rs/cblas/pull/5
• lapack https://github.com/blas-lapack-rs/lapack/pull/26
• lapacke https://github.com/blas-lapack-rs/lapacke/pull/4

Is there a way to support switching backends depending on the OS target (eg, if mac or linux)?

I tried specifying my cargo.toml with platform specific dependencies like:

cargo.toml

[target.'cfg(target_os = "macos")'.dependencies]
lapack = "0.16.0"
blas = "0.20.0"
lapack-src = { version = "0.6", features = ["accelerate"] }
accelerate-src = "0.3.2"

[target.'cfg(target_os = "linux")'.dependencies]
lapack = "0.16.0"
blas = "0.20.0"
lapack-src = { version = "0.6", features = ["openblas"] }
openblas-src = "0.9"

lib.rs

extern crate blas;
extern crate lapack;
extern crate lapack_src;

#[cfg(target_os = "macos")]
extern crate accelerate_src;

#[cfg(target_os = "linux")]
extern crate openblas_src;

but I get the error:

 --> ... lapack-src-0.6.0/src/lib.rs:43:1
   |
34 | extern crate accelerate_src as raw;
   | ----------------------------------- previous import of the extern crate `raw` here
...
43 | extern crate openblas_src as raw;
   | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ `raw` reimported here
   |
   = note: `raw` must be defined only once in the type namespace of this module
help: you can use `as` to change the binding name of the import
   |
43 | extern crate openblas_src as other_raw;

For example, the iter argument to dsgesv is a single integer, but the bindings here have it represented as an &mut [i32] rather than &mut i32.

Hi, I managed to get Apple's Accelerate.framework packaged up and published to crates.io. It would be create if you could merge this and make a new release. Thanks!

I have the following dependencies in Cargo.toml

lapack = "0.17.0"
lapack-src = { version="0.8.0", features=["openblas"]}

When I use functions from lapack in my crate, I get linker errors (undefined symbols). This can be solved by adding extern crate lapack_src as _; to my crate, but this behavior is a footgun, as debugging it requires understanding rust linkage model (and its interaction with cargo). As far as I understand it, the issue would be solved if an upstream crate would depend on lapack-src itself.

Could this be done here ? Or would it be better to do it in lapack-sys ?