Remove the explicit linking to gfortran

[IvanUkhov]

It’s been suggested to remove the link to gfortran; see blas/#28.

However, a few questions have to be answered first. How would it work in this case? Who would do the linking instead? The claim is that “the libopenblas.dylib built by the Makefile is correctly linked to gfortran.” How will it work on platforms other than macOS?

[MrGibus]

I think this issue is actually at the heart of many others. I still don't know what purpose the gfortran library serves, but I also came to the conclusion that removing it solves many build issues. --can you confirm that it's absolutely required on linux? if so then why is it required?

quick edit: the build script I'm using is that of 0.9. I haven't modified the 0.10 scripts.

(I'm on windows 10.)

TLDR: gfortran.lib is not required, MSYS2 is not required to build on windows. anyone trying to link to another file should place the link in [target.] not [build]

steps for others to recreate:

1. I built openBLAS on vcpkg as you have done and moved the resulting openBLAS.lib file to an easy to reach directory.
2. in config.toml add the rustflags linking to your directory
3. fixing the gfortran reference
   Option 1. comment out 66: println!("cargo:rustc-link-lib=dylib=gfortran"); in build.rs
   Option 2. make a fake file called gfortran.lib and place it in the same directory as openBLAS.lib

Test code

extern crate libc; // may not be needed
extern crate openblas_src;

use libc::c_float;

extern "C" {
    pub fn srotg_(a: *mut c_float, b: *mut c_float, c: *mut c_float, s: *mut c_float);
}

#[test]
fn link_test() {
    unsafe {
        let mut a: f32 = 0.0;
        let mut b: f32 = 0.0;
        let mut c: f32 = 42.0;
        let mut d: f32 = 42.0;
        srotg_(
            &mut a as *mut _,
            &mut b as *mut _,
            &mut c as *mut _,
            &mut d as *mut _,
        );
        assert_eq!(c, 1.0);
        assert_eq!(d, 0.0);
    }
}

Default build:

[dependencies]
libc = "0.2.77"
openblas-src = "0.9.0"

Build Result:

error: failed to run custom build command for openblas-src v0.9.0

Caused by:
process didn't exit successfully: C:\Users\... target\debug\build\openblas-src-7a51b9204dc86205\build-script-build (exit code: 101)
--- stdout
Running: "cp" "-R" "source" "..build/openblas-src-24c1b2bbe8a397a9/out\source_x86_64-pc-windows-msvc_tmp"

--- stderr
thread 'main' panicked at 'Failed:"cp" "-R" .(The system cannot find the file specified. (os error 2))', openblas-src-0.9.0\build.rs:79:13

This was expected

system build

[dependencies]
libc = "0.2.77"
openblas-src = {version = "0.9.0", features=["system"]}

Build Result:

Build successful.

Test Build:

error: linking with link.exe failed: exit code: 1181
|
= note: "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.27.29110\bin\HostX64\x64\link.exe"
"/NOLOGO" "/NXCOMPAT" "/LIBPATH:C:\Users\me\.rustup\toolchains\stable-x86_64-pc-windows-msvc\lib\rustlib\x86_64-pc-windows-msvc\lib"
..< long error > ..
"kernel32.lib" "gfortran.lib" "openblas.lib" "advapi32.lib" "ws2_32.lib" "userenv.lib" "libcmt.lib"
= note: LINK : fatal error LNK1181: cannot open input file 'gfortran.lib'

Interpretation:

This is where my confusion starts
not sure what the purpose of gfortran.lib is if openblas.lib is statically built?
Reference to gfortran specifically? - same after installing mingw64 w/gfortran compiler

static-system build - attempt 1

[dependencies]
libc = "0.2.77"
openblas-src = {version = "0.9.0", features=["system", "static"]}

Build Result:

error: could not find native static library openblas, perhaps an -L flag is missing?

static system build - attempt 2

config.toml=
[build]
rustflags = ["-L", "C:/Users/me/.lib"] # This directory contains openblas.lib

cargo.toml=
[dependencies]
libc = "0.2.77"
openblas-src = {version = "0.9.0", features=["system", "static"]}

Build Result:

warning: unused manifest key: build
error: could not find native static library openblas, perhaps an -L flag is missing?

static system build - attempt 3

config.toml=
[target.x86_64-pc-windows-msvc] # instead of using 'build' I added the flags to the target
rustflags = ["-Ctarget-feature=+crt-static", "-L", "C:/Users/me/.lib"]

cargo.toml=
[dependencies]
libc = "0.2.77"
openblas-src = {version = "0.9.0", features=["system", "static"]}

Build Result:

Build successful

Test build:'

build failed
.rlib" "kernel32.lib" "gfortran.lib" "advapi32.lib" "ws2_32.lib" "userenv.lib" "libcmt.lib"
= note: LINK : fatal error LNK1181: cannot open input file 'gfortran.lib'

notes:

Progress: openblas.lib no longer noted in error, still not sure what gfortran.lib is?

Building with ubuntu bash terminal:

cargo.toml=
[dependencies]
libc = "0.2.77"
openblas-src = "0.9.0"

Build Result

Finished dev [unoptimized + debuginfo] target(s) in 2m 32s
Seems to have compiled?

Test Build:

error: linking with cc failed: exit code: 1
|
= note: "cc" "-Wl,--as-needed" ...
...libcompiler_builtins-d61dbae1fa88f6f5.rlib" "-Wl,-Bdynamic" "-lgfortran" "-lopenblas" "-lutil" "-ldl" "-lutil"
"-ldl" "-lrt" "-lpthread" "-lgcc_s" "-lc" "-lm" "-lrt" "-lpthread" "-lutil" "-lutil"
= note: /usr/bin/ld: cannot find -lgfortran
collect2: error: ld returned 1 exit status

above with system

= note: /usr/bin/ld: cannot find -lgfortran
/usr/bin/ld: cannot find -lopenblas
collect2: error: ld returned 1 exit status

Notes:

Builds .so and .a files
This might cause issues building on windows.

Building with MSYS2:

cargo.toml=
[dependencies]
libc = "0.2.77"
openblas-src = "0.9.0"

Build Result

builds

Test Build:

= note: C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lgfortran
collect2.exe: error: ld returned 1 exit status
still have gfortran issues

above with system

= note: C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lgfortran
C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/10.2.0/../../../../x86_64-w64-mingw32/bin/ld.exe: cannot find -lopenblas
collect2.exe: error: ld returned 1 exit status

notes:

Builds far slower than other methods
returns

• cygopenblas.dll
• "libopenblas.dll.a"
• cygopenblas.a

no '.lib' files
no gfortran
a comment noted that MSYS2 pacman doesn't always build libraries fully
#28
everything seems installed fine - reran 'pacman -S mingw-w64-x86_64-gcc-libgfortran' a few more times anyway but no change

hunch: make a fake file and call it gfortran.lib

[dependencies]
libc = "0.2.77"
openblas-src = {version = "0.9.0", features=["system"]}

Build Result:

Build successful.

Test Build:

link_test passing.

notes:

gfortran.lib is not needed. On windows .lib files can be linked statically if configured properly

editing build.rs

line 63:

println!("cargo:rustc-link-lib=dylib=gfortran"); // not required on windows, maybe not even linux?

related: #20

[IvanUkhov]

@termoshtt, you are probably in a better position to evaluate this.

[termoshtt]

I've restore linking to Fortran runtime using openblas-build #44 in #43 and #52 .

openblas-build crate sneaks OpenBLAS build system, say Makefile.conf generated by Makefile.prebuild to get the result of Fortran compiler detection by OpenBLAS. Example Makefile.conf is placed at https://github.com/blas-lapack-rs/openblas-src/blob/master/openblas-build/Makefile.conf for testing parser. It sets FEXTRALIB variable which includes -lgfortran and where it exists as -L flag. This will be converted into rustc linker flags in openblas-src/build.rs https://github.com/blas-lapack-rs/openblas-src/blob/master/openblas-src/build.rs#L118

I expect it works also for Intel #17 or other Fortran compiler e.g. flang and nvfortran (a.k.a PGI Fortran), but it is not tested them yet.

[IvanUkhov]

@termoshtt, this can be closed, right?