Cimpile OpenBLAS 0.2.20 Failed under Windows 10 X64 with msys2

[strategist922]

Hi,
I try to use MSYS2 to compile OpenBLAS 0.2.20, with following flags, but it show me error ag begining

$ make QUIET_MAKE=1 TARGET=NEHALEM DYNAMIC_ARCH=1 HOSTCC=gcc NUM_THREADS=64 BINARY=64 CC=x86_64-w64-mingw32-gcc FC=x86_64-w64-mingw32-fortran
ln: failed to create symbolic link 'libopenblas.a': No such file or directory
make: [Makefile:138: libs] Error 1 (ignored)..

Does anyone know how to solve this issus?

thanks in advance!

[martin-frbg]

Is this the only message you got ? Creating the link happens late in the build process...

[brada4]

Please remove bold formatting
fortran compiler is called x86_64-w64-mingw32-gfortran

[strategist922]

The error message as following:
Warning: 「nargs」 may be used uninitialized in this function [-Wmaybe-uninitialized]
gfortran -O3 -Wall -m64 -o sblat2 sblat2.obj ../libopenblas_haswell-r0.2.20.a -defaultlib:advapi32 -lgfortran -defaultlib:advapi32 -lgfortran
../libopenblas_haswell-r0.2.20.a(sgemv.obj):gemv.c:(.text+0x24f): 未定義參考到 _assert
../libopenblas_haswell-r0.2.20.a(sgemv.obj):gemv.c:(.text+0x24f): 截斷重定址至相符: R_X86_64_PC32 針對未定義的符號 _assert
../libopenblas_haswell-r0.2.20.a(sger.obj):ger.c:(.text+0x1a7): 未定義參考到 _assert
../libopenblas_haswell-r0.2.20.a(sger.obj):ger.c:(.text+0x1a7): 截斷重定址至相符: R_X86_64_PC32 針對未定義的符號 _assert
../libopenblas_haswell-r0.2.20.a(memory.obj):memory.c:(.text+0x1b4): 未定義參考到 __imp__cprintf
../libopenblas_haswell-r0.2.20.a(memory.obj):memory.c:(.text+0x1b4): 截斷重定址至相符: R_X86_64_PC32 針對未定義的符號 __imp__cprintf
../libopenblas_haswell-r0.2.20.a(memory.obj):memory.c:(.text+0x36d): 未定義參考到 __imp__cprintf
../libopenblas_haswell-r0.2.20.a(memory.obj):memory.c:(.text+0x36d): 截斷重定址至相符: R_X86_64_PC32 針對未定義的符號 __imp__cprintf
collect2: 錯誤：ld 回傳 1
make[1]: *** [Makefile:144: sblat2] Error 1
make[1]: Leaving directory '/c/temp/openblas-0.2.20/test'
make: *** [Makefile:117: tests] Error 2

My GCC informaation:
$ gcc -v
Using built-in specs.
COLLECT_GCC=C:\msys64\mingw64\bin\gcc.exe
COLLECT_LTO_WRAPPER=C:/msys64/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/7.2.0/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: ../gcc-7.2.0/configure --prefix=/mingw64 --with-local-prefix=/mingw64/local --build=x86_64-w64-mingw32 --host=x86_64-w64-mingw32 --target=x86_64-w64-mingw32 --with-native-system-header-dir=/mingw64/x86_64-w64-mingw32/include --libexecdir=/mingw64/lib --enable-bootstrap --with-arch=x86-64 --with-tune=generic --enable-languages=c,lto,c++,objc,obj-c++,fortran,ada --enable-shared --enable-static --enable-libatomic --enable-threads=posix --enable-graphite --enable-fully-dynamic-string --enable-libstdcxx-time=yes --disable-libstdcxx-pch --disable-libstdcxx-debug --disable-isl-version-check --enable-lto --enable-libgomp --disable-multilib --enable-checking=release --disable-rpath --disable-win32-registry --disable-nls --disable-werror --disable-symvers --with-libiconv --with-system-zlib --with-gmp=/mingw64 --with-mpfr=/mingw64 --with-mpc=/mingw64 --with-isl=/mingw64 --with-pkgversion='Rev1, Built by MSYS2 project' --with-bugurl=https://sourceforge.net/projects/msys2 --with-gnu-as --with-gnu-ld
Thread model: posix
gcc version 7.2.0 (Rev1, Built by MSYS2 project)
But..
$ gfortran -v
使用內建 specs。
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-msys/6.3.0/lto-wrapper.exe
目的：x86_64-pc-msys
配置為：/msys_scripts/gcc/src/gcc-6.3.0/configure --build=x86_64-pc-msys --prefix=/usr --libexecdir=/usr/lib --enable-bootstrap --enable-shared --enable-shared-libgcc --enable-static --enable-version-specific-runtime-libs --with-arch=x86-64 --with-tune=generic --disable-multilib --enable-__cxa_atexit --with-dwarf2 --enable-languages=c,c++,fortran,lto --enable-graphite --enable-threads=posix --enable-libatomic --enable-libcilkrts --enable-libgomp --enable-libitm --enable-libquadmath --enable-libquadmath-support --enable-libssp --disable-win32-registry --disable-symvers --with-gnu-ld --with-gnu-as --disable-isl-version-check --enable-checking=release --without-libiconv-prefix --without-libintl-prefix --with-system-zlib --enable-linker-build-id --with-default-libstdcxx-abi=gcc4-compatible
執行緒模型：posix
gcc version 6.3.0 (GCC)

[ghost]

I encountered the same problem when compiling OpenBLAS-0.2.20 using MSYS2 + MingW64. At the end of August, I have encountered this problem, so I switched to CMake + VisualStudio plan. But for some reason, I want to use MingW32(64) to get OpenBLAS compilation done. I retried today but sadly got the same error.

Error log(MSYS2 + MingW64):

make[1]: Warning: File '../libopenblas_nehalemp-r0.2.20.a' has modification time 0.69 s in the future
gfortran -O2 -Wall -m64 -o sblat1 sblat1.obj ../libopenblas_nehalemp-r0.2.20.a -defaultlib:advapi32 -lgfortran -defaultlib:advapi32 -lgfortran
../libopenblas_nehalemp-r0.2.20.a(memory.obj):memory.c:(.text+0x2f4): undefined reference to __imp__cprintf' ../libopenblas_nehalemp-r0.2.20.a(memory.obj):memory.c:(.text+0x2f4): relocation truncated to fit: R_X86_64_PC32 against undefined symbol __imp__cprintf'
../libopenblas_nehalemp-r0.2.20.a(memory.obj):memory.c:(.text+0x43c): undefined reference to __imp__cprintf' ../libopenblas_nehalemp-r0.2.20.a(memory.obj):memory.c:(.text+0x43c): relocation truncated to fit: R_X86_64_PC32 against undefined symbol __imp__cprintf'
collect2: error: ld returned 1 exit status
make[1]: *** [Makefile:129: sblat1] Error 1
make[1]: Leaving directory '/i/t/OpenBLAS-0.2.20/OpenBLAS-0.2.20/test'
make: *** [Makefile:117: tests] Error 2

Static library seems to be created, but I want to get the libopenblas.dll and libopenblas.dll.a .

Moreover, I can't compile openBLAS 0.2.20 using MSYS2 + mingw32 . I forgeted to copy the error log. It was said like this:

gfortran -mincoming-stack-boundary=2 is not between 3 and 12.

I forcefully changed mincoming-stack-boundary to 3, then the compiler died by segment fault. It is really wired.

Finally I tried MSYS and MingW32 to compile libopenblas.dll and libopenblas.dll.a . Luckily, it is passed.

[ghost]

I have done some search, I was told to do "make clean" first. I tried to make clean at the beginning, but still
got the same error.

[martin-frbg]

Could it be you are (both) missing the "w32api" package in your mingw installation ? (BTW I fixed the formatting in the first message - inline "markdown" styling certainly has some surprises for those not familiar with it)

[brada4]

Future time might be caused by using network share on server with time not in sync setting access time using its own clock. Get both client and server syncing from same time source.

Try this:
script
LANG=C LC_ALL=C make (your parameters)
exit

Now upload typescript file.

[martin-frbg]

@brada4 I doubt this is a timestamp issue, as both assert and cprintf will be provided by a system library.

[brada4]

Linux virtual machine works (for me) in all cases. It needs pthread and gfortran dll-s from compact mingw there. Either can be missing in mingw.

[ghost]

I compiled in the same PC machine. I think the timestamp warning is related to the fact that I used ramdisk to compile the code. It seems no such warnning when I compile the code in harddrive space.

[ghost]

@martin-frbg I have already inmsys/msys2-w32api-headers and msys/msys2-w32api-runtime

[strategist922]

I install latest MSYS2 with GCC 7.2.0 tool chain and can compile openBLAS 0.2.20
but after install, there is no libopenblas.dll
May I know how to fix this issue?

[ghost]

@brada4 I just installed mingw-w64-x86_64-gcc-fortran,and it works! Thanks!

[ghost]

strategist922 I used mingw64 + msys2. There is libopenblas.dll in the source folder.

[strategist922]

@AttufliX Oh...I found it, thanks

[martin-frbg]

@brada4 good catch. Seems the wiki page is not at all clear on which parts of mingw need to be installed for building OpenBLAS, and that confused/confusing error message from the linker may even warrant an entry in the faq ?

[brada4]

It should skip all fortran components (LAPACK) in absence of compiler and hopefully wrongly set compiler too.
Without log capture it is hard to tell what went wrong.

[martin-frbg]

It certainly should, I wonder if either there is a breakdown of the Makefile logic (requiring libgfortran in the tests although it was found to be absent in the build phase), or - more likely IMHO - it is possible to install a mingw gfortran without the associated libraries. (Sort of like some Linux distributions split it into a main "gcc-gfortran" and separate "gfortran-devel" or "libgfortran" package). The wiki page only states to "install" mingw-w64 without detailing the process or the list of components.

[brada4]

@martin-frbg I will add proper command to faq this or next week. I think the hidden issue is that native gfortran here is almost identical to cross-gfortran and if they get mixed up it is not exactly producing absolutely invalid module.

[ghost]

I think it is very necessary to point out installing mingw-w64-x86_64-gcc-fortran explicitly.

[brada4]

Yup, I will just list what is needed on top of smallest possible mingw install.

[martin-frbg]

Without gfortran, there should have been a warning about only being able to build the BLAS component, and the tests should not have been built. So this situation can only come about if there is something else somewhere in the executable search path that acts like gfortran but is not usable for the mingw build.
From what strategist922 posted above, his "gfortran -v" shows a different - older - version number, and its install location appears to be different as well (the LTO_WRAPPER is set to a unix-like path).
It is quite possible that there is an ABI mismatch between gcc-7.2 and gfortran-6.3, @AttufliX if you were experimenting with mingw a few weeks ago, could it be that you had a gfortran from an older
mingw still installed on the system, just usable enough to mess with your OpenBLAS build as well ?
(Perhaps it would make sense to have the f_check tool check for version mismatches between gcc and gfortran and issue a warning ?)

[brada4]

I was thinking of what FAQ this is and came to conclusion that:
(1) gcc and gfortran should be same
(2) cross-builds where cross-fortran is absent will pick up host gfortran and make mess
I wonder if echoing CC and CFLAGS and cc --version at start of build could help people to understand this unassisted....

[ghost]

@martin-frbg This is my pacman log.

[2017-08-30 19:06] [ALPM] installed gcc-fortran (6.3.0-1)
[2017-09-20 16:00] [PACMAN] Running 'pacman -Su mingw-w64-x86_64-gcc-fortran'

It's clear that gcc-fortran cannot compile the the LAPACK part of openBLAS, but mingw-w64-x86_64-gcc-fortran could.

[brada4]

gcc and gfortran should be from same package.
it is not about f77 language, anything in last 40 years can do that, it is about incompatible low-level runtimes behind the scenes.

[martin-frbg]

I have now modified the wiki page a bit:

Build OpenBLAS on Windows OS

Install the MinGW (GCC) compiler suite, either 32-bit (http://www.mingw.org/) or 64-bit (http://mingw-w64.sourceforge.net/). Be sure to install its gfortran package as well (unless you really want to build the BLAS part of OpenBLAS only) and check that gcc and gfortran are the same version - mixing compilers from different sources or release versions can lead to strange error messages in the linking stage. In addition, please install MSYS with MinGW.