Trying to build in Windows10 with IntelLLVM

[sephenisee]

Hello,

I am trying to build OpenBLAS in Windows with Intel's C and Fortran compilers. I am also using VS2022 preview for build environment.
Intel made their IntelLLVM compilers icx for C language and ifx for Fortran as default, and it seems to cause some conflict with prebuild setup.

In the x64 Native Tools, I activate the Intel's environment. Then, I try to configure by executing the line: cmake .. -G "Ninja" -DCMAKE_CXX_COMPILER=icx -DCMAKE_C_COMPILER=icx -DCMAKE_Fortran_COMPILER=ifx -DCMAKE_MT=mt -DBUILD_WITHOUT_LAPACK=no -DNOFORTRAN=0 -DDYNAMIC_ARCH=OFF -DCMAKE_BUILD_TYPE=Release

It tries to compile the cpuid.S, which seems to be ARM related and gives other error messages.
Full error messages are copied in configure_errors.txt files.
configure_errors.txt

In the prebuild.cmake, should I edit the line so that it configures with -DFORCE_GENERIC like MSVC?

Thank you in advance,
Sean

[martin-frbg]

Hmm, I've read in other contexts that the 2025 version is not yet correctly handled by CMake. I'm fairly certain that icx used to be able to process cpuid.S - which contains only conditionally-compiled i386 assembly for ancient Macs anyway.

I think you could try just removing the list (append getarch_src line in prebuild.cmake that adds cpuid.S to the compilation - forcing everything to use the generic C kernels would cost quite a bit of performance. (Though you might run into similar errors with other .S files later on - for the moment I hope it is only CMake getting confused, and not the compiler - ".S" is an "ASM" file so it should not balk at it.

BTW which version of OpenBLAS are you trying to build - is it 0.3.28 (or develop) ?

[sephenisee]

Thanks for the prompt response. Commenting out the line you mention helped to complete the configuring process. I cloned the develop branch.
During the build, it complains about the _Fcomplex and _Dcomplex. I already had some experience with this. I believe IntelLLVM for MSVC environment does not follow MSVC complex ... Also, it does not seem to support C99 in Windows environment.
I think the easiest option is to define LAPACK_COMPLEX_STRUCTURE in lapacke_config.h. Do you have other suggestions?

[martin-frbg]

I'm not sure - where does it complain ? LAPACK_COMPLEX_STRUCTURE should already get defined by system.cmake line 670 when the operating system is identified as Windows, so something seems to be odd here.

[sephenisee]

The line 71 in lapacke_config.h has $if defined(_MSC_VER) and it defines _CRT_USE_C_COMPLEX_H and uses MSVC complex definition.
I just edited it to "_MSC_VER1" so it does not go through that condition, so it automatically defines LAPACK_COMPLEX_STRUCTURE. After this change, the build process proceeds but I get a bunch of link errors at the end.
It looks like openblas.lib is built, but many of external symbols are undefined, causing unresolved external symbol.
For example, I tried to build only cblat1.exe. I get linking error message: unresolved external symbol CAXPY referenced in function HEADER. All the externals in function HEADER are not resolved.

[martin-frbg]

Does icx define _MSC_VER ? I'd normally assume this to be set by the Microsoft compiler, maybe the ifdef needs to be expanded to include "but not Intel". Not sure why you'd get a bunch of link errors now, unless building the caxpy kernel (or its interface code) failed earlier.

[sephenisee]

I forgot which CMake file I saw this, but I remember that the compiler-frontend-variant and compiler-simulate-id are MSVC for IntelLLVM. Do you think these might be related?
I will try to see if kernel or the interface code are compiled properly.

[martin-frbg]

Could be related, yes. But then this does not appear to have caused problems in the past (unless it is a very recent change in the Intel compiler package, and as said there are some concerns about its interfacing with current CMake). Might also want to check if the "missing symbol" problem only affects complex functions, or if you get the same for sblat1/saxpy.

[sephenisee]

I am checking the external symbols in openblas.lib. It looks like caxpy symbols have underscore "_". Do you think this might be related to the linking issue? I attached the image of output from dumpbin.

[martin-frbg]

Seems unlikely to me but I can't rule it out. The CMake build has a few compiler specifics hardcoded (or relying on CMake's own checks) that the gmake build calls the c_check and f_check scripts for. But so far these settings worked... I'll see if I can set up a quick test tomorrow (getting a bit late here already)

[sephenisee]

Thank you so much for your help today!

[martin-frbg]

Haven't quite succeeded yet, unfortunately. So far, I got the build to use consistent (no) trailing underlines on symbol names, but I cannot get CMake to include build instructions for the assembly (.S) kernels in the Ninja build file. (CMake appears to identify the compiler/assembler correctly as IntelLLVM though, and invoking icx manually on any .S file generates an object without complaint as well.)

[sephenisee]

Thanks for the update. I was not able to get much progress either on linking. I am trying to see if there were any problems during the compilation of the library. Missing symbol problem also appears for sblat1/saxpy and for dblat1/daxpy. Please let me know if you have any suggestion for me to try.

[sephenisee]

It looks like ifx uses Uppercase without trailing underscore for name mangling for Fortran. But symbols in openblas.lib after compilation are stored following gfortran name mangling convention which is lowercase with trailing underscore. What would you suggest in editing CMake file(s) so that .f.obj files and openblas.lib have same name mangling style?

[parteimeister]

I also encountered this problem. As a temporary solution - you can compile the library with dynamic linking using MinGW and use it in a project with the MSVC compiler. As far as I remember, the library compiled this way does not pass testing, but this seems to be a bug in the tests themselves. Nevertheless, this option is definitely suitable if you plan to use the library as a dependency for the Eigen library in a CMake project on Windows.

[martin-frbg]

When you compile with dynamic linking on Windows, the tests currently require the freshly created dll to be in the path (or in the same place as the respective test executable), which will not be the case...
I haven't found an explanation for the problem with Ninja yet (seems this occured before with an earlier version of cmake, but should be fixed since 3.23 or so - I think my Windows setup has 3.29.something, which may not be the latest anymore either... Trying with `-G "MinGW Makefiles" currently ends up with "rc.exe not found" but that may be a path setup problem between oneAPI and MSVC... I think I saw that before but can't remember the solution...

[martin-frbg]

@parteimeister it won't find output files for checking if the tests weren't run - the BLAS2/3 tests write their output to file which the helper script then checks for occurrence of the word "FAILED". But anyway that is a wholly different topic

[sephenisee]

@parteimeister Thank you for your suggestion on the temporary solution using dynamic linking with MinGW.

@martin-frbg I am still interested in solving this issue but I don't want to bother you too much on this, especially close to holiday season. If you think there is no simple solution, I can try with MinGW as @parteimeister suggested. Do you think this issue may be considered to be fixed by next release?

[sephenisee]

I wrote a .asm that maps ifx's default naming to gfortran naming convention just to build 'dblat1.exe', and added this during the linking process.
It looks like there is another issue on openblas.lib. After compilation, I get .S files for some kernel files such as dcopy_k.S, dnrm2_k.S and etc. That seems to be related on why dcopy_k, dnrm2_k, and etc are undefined in openblas.lib. Besides the inconsistency in the name mangling, this .S files also seem to cause trouble with IntelLLVM and Window's VS2022 combination with current prebuild.cmake.

[martin-frbg]

This is what I wrote yesterday - the erroneous underscores added to the symbols can be worked around, actually they are the result of a bad assumption in the cmake files that "every" compiler will produce/want them anyway. (In contrast, the gmake build runs a shell script that parses compiler output to find out). The main issue however is that while the CMake environment creates all the correct build wrappers for the .S files, it apparently does not write the corresponding build
rules into the build.ninja file. This appears to be a fault of CMake, most likely specific to its interaction with the very new Intel2025 as it did not happen in the past.

[sephenisee]

I see ... Thanks for the explanation on the main issue.

[martin-frbg]

Major progress - the assembler problem can be solved by additionally specifying -DCMAKE_ASM_SOURCE_FILE_EXTENSIONS=S (although .S is one of the documented defaults already, and we saw it in the initial error message for cpuid.S).
Now the build of the "extended" utests is failing due to a symbol clash between the BLAS ?copy and a local utility function of the same name, but the library itself looks good