Unable to build BLAS - complex.h missing

[balamurata123]

Hello,

I am currently trying to build BLAS as it is needed for another code I will be using - NEML (https://github.com/Argonne-National-Laboratory/neml). My current setup is Win 10, Visual Studio 2012 with installed Intel Parallel 2015.

I have followed the steps for installing OpenBlas from https://github.com/xianyi/OpenBLAS/wiki/How-to-use-OpenBLAS-in-Microsoft-Visual-Studio, but the Conda Prompt exited with an error during the build - ninja: build stopped: subcommand failed. ; see attached output from the shell. It appears that build encountered an error in not finding complex.h.
Would it be possible to get some feedback on what the issue might be and how it could be resolved? I can provide any info needed to help resolve this. Sadly I am restricted to using Windows because of other softwares which will later use the above NEML model which requires BLAS.
Many thanks all
Anaconda Prmt - BLAS.txt

[brada4]

cmake is introduced here well after 2012. Please use mingw make ONLY.

[balamurata123]

Hi @brada4 , is the mingw installation method described anywhere I can access and follow? I am a rookie programmer and it would certainly help. Thanks

[brada4]

It is to type command make , and Makefiles will figure out available compilers and options. It stands that way on the front page for a decade or so.

[martin-frbg]

I do not think this is a cmake vs gmake problem. As far as I know, support for C99 features like complex.h was added at or around VS2017 so complex.h may not have been available in Visual Studio 2012. If you also have the Intel compiler installed, maybe it is only a question of setting CMAKE_C_COMPILER to point to icc instead ? Another option could be to install a more recent version of VS (community edition probably) unless NEML absolutely requires VS2012. (From the git history, the requirement for complex.h in that kernel file was added in 2015)

[balamurata123]

Ok, I installed chocolatey and then installed make. After that, I opened cmd, cd to \OpenBLAS and make . The result does not seem correct.. :

D:\GITlib\OpenBLAS>make
process_begin: CreateProcess(NULL, uname -m, ...) failed.
Makefile.system:14: pipe: No error
The system cannot find the path specified.
process_begin: CreateProcess(NULL, uname -s, ...) failed.
Makefile.system:56: pipe: Bad file descriptor
process_begin: CreateProcess(NULL, gcc -DGEMM_MULTITHREAD_THRESHOLD=4 -DNO_PARALLEL_MAKE=0 -o getarch getarch.c cpuid.S, ...) failed.
make (e=2): The system cannot find the file specified.
make: *** [Makefile.prebuild:70: getarch] Error 2
process_begin: CreateProcess(NULL, uname -m, ...) failed.

I guess I am missing something?

[martin-frbg]

This now seems to go looking for the gcc compiler rather than MSVC.

[martin-frbg]

Digging deeper, it seems that the #include <complex.h> in kernel/x86_64/cdot.c` is actually redundant, as common.h will already
include either this header or a suitable non-C99 workaround. Could you try deleting the offending line from cdot.c ? (I have checked that this works on Linux, but I cannot readily try on Windows with VS2012)

[balamurata123]

Hi Martin, I will delete the line from cdot.c and try again the method posted in https://github.com/xianyi/OpenBLAS/wiki/How-to-use-OpenBLAS-in-Microsoft-Visual-Studio, which I used previously failing. Will share result in a bit.

[balamurata123]

After removing <complex.h> from cdot.c, the build continued up to [12718/17241] but failed again due with the following:

[12718/17241] Building C object utest\CMakeFiles\openblas_utest.dir\test_kernel_regress.c.obj
FAILED: utest/CMakeFiles/openblas_utest.dir/test_kernel_regress.c.obj
C:\Users\Mark\miniconda3\Library\bin\clang-cl.exe  /nologo  -I..\lapack-netlib\LAPACKE\include -I..\ -I. /DWIN32 /D_WINDOWS /W3  -DHAVE_C11 -DMS_ABI -Wall -m64 -DF_INTERFACE_FLANG -DDYNAMIC_ARCH -DSMP_SERVER -DMAX_CPU_NUMBER=8 -DMAX_PARALLEL_NUMBER=1 -DNO_AFFINITY -DVERSION="\"0.3.15.dev\"" -DBUILD_SINGLE -DBUILD_DOUBLE -DBUILD_COMPLEX -DBUILD_COMPLEX16 /MD /O2 /Ob2 /DNDEBUG /Zi /showIncludes /Foutest\CMakeFiles\openblas_utest.dir\test_kernel_regress.c.obj /Fdutest\CMakeFiles\openblas_utest.dir\ -c -- ..\utest\test_kernel_regress.c
In file included from ..\utest\test_kernel_regress.c:1:
..\utest/openblas_utest.h(35,9) : warning: macro name is a reserved identifier [-Wreserved-id-macro]
#define _OPENBLAS_UTEST_H_
        ^
In file included from ..\utest\test_kernel_regress.c:1:
In file included from ..\utest/openblas_utest.h:38:
In file included from ..\utest/ctest.h:31:
C:\Users\Mark\miniconda3\Library\lib\clang\11.0.1\include\inttypes.h(18,2) : error: MSVC does not have inttypes.h prior to Visual Studio 2013
#error MSVC does not have inttypes.h prior to Visual Studio 2013
 ^
C:\Users\Mark\miniconda3\Library\lib\clang\11.0.1\include\inttypes.h(21,15) : fatal error: 'inttypes.h' file not found
#include_next <inttypes.h>
              ^~~~~~~~~~~~
1 warning and 2 errors generated.

...

[12727/17241] Generating Fortran dyndep file CMakeFiles\openblas.dir\Fortran.dd
ninja: build stopped: subcommand failed.

It appears that it has an issue with the version of VS - do you think there is way to bypass this as for complex.h. Alternatively, I could try using the make approach. Would this require adding an env variable CMAKE_C_COMPILER to Intel C compiler?
To answer your question Martin, I am needing NEML (and respectively BLAS) for the structural solver Ansys. Ansys versions only accept specific versions of VS and Intel Parallel, and as I have an old version of Ansys currently I have to stick to VS2012. Thanks!

[martin-frbg]

utest/ctest.h will need changing so that it includes stdint.h instead, and uses literal %u and %d in its printf statements
Something like this will probably work (remove the .txt when saving)
ctest.h.txt

[balamurata123]

Hi Martin, thanks for the feedback but the method of changing ctest.h did not work. Failed at inttypes.h again. I will probably have to accept defeat here but thanks for your help!

[martin-frbg]

strange, from what I had seen on the net I assumed vs2012 would not define STDC_VERSION at all, so I used that to decide which to include.
Did you make sure that the "new" ctest.h ended up in the utest folder ?
(the less elegant solution would be to remove utest from the cmake targets)

[martin-frbg]

(i.e. remove the line add_subdirectory(utest) from the toplevel CMakeLists.txt)

[balamurata123]

Yes the new test was copied to utest folder as a .h file. Ok, I will this method without add_subdirectory(utest)

[balamurata123]

Update: It did build and install with your suggestion Martin; thank you! I can see however that when trying to compile the NEML software, it does not find the BLAS library. Is there a need to define any env var to the OpenBLAS folder so that cmake recognises it? Cmake documentation tells me it should recognise OpenBLAS without any additional work. I will probably raise a question to NEML folks on their git for this and close this issue as solved here.

CMake Error at D:/GITlib/cmake/share/cmake-3.20/Modules/FindPackageHandleStandardArgs.cmake:230 (message):
  Could NOT find BLAS (missing: BLAS_LIBRARIES)