Compile error on Windows on Arm #4714
Comments
|
Sorry, I am not aware if anybody tried to compile OpenBLAS on/for Windows on Arm yet, and I do not currently have (access to) such a system. |
|
Thanks for the fast reply. Will look further into the c_check script.
|
|
What do you have in the (generated) files Makefile.conf and config.h - do they look sane ? |
|
I seem to see most of the options, Armv8, 64 bits, Windows NT, number of threads there. config.h Makefile.conf |
|
Yes, this looks "mostly" sane except that it appears to "think" that you are cross-compiling, and it apparently did not find a fortran compiler. Maybe Windows-on-Arm identifies as something other than "arm64" or "aarch64" ? |
|
Ah, I now see that you set HOSTCC, which is only necessary for cross-compiling (and automatically implies cross-compiling). Not sure if that has any bearing on the other errors though... |
|
BTW the |
|
Will try in a few, when my current build attempt finishes (or fails). I noticed that the file pathes for CEXTRALIB are cut (seems to only get the part before the space in the path since on windows some of the *.h files are in Seems they are parsed from check_c Whats the best way to get the logs out? Pipe them in a file or is there an additional flag? |
|
piping to file, there is no additional flag or infrastructure for that |
|
Okay here's the build log with make CC="clang-cl" AR="llvm-ar" BUILD_WITHOUT_LAPACK=0 NOFORTRAN=0 DYNAMIC_ARCH=0 TARGET=ARMV8
ARCH=arm64 BINARY=64 USE_OPENMP=0 PARALLEL=1 RANLIB="llvm-ranlib" MAKE=make F_COMPILER=FLANG
FC=FLANG FFLAGS_NOOPT="-march=armv8-a -cpp" FFLAGS="-march=armv8-a -cpp" NEED_PIC=0 HOSTARCH=arm64
CCOMMON_OPT=-w FCOMMON_OPT="-Wno-override-module" USE_THREAD=1 NUM_THREADS=8 OSNAME=WINNT libs netlibI had to add I was getting all over. Build Log
clang-cl: warning: unknown argument ignored in clang-cl: '-S' [-Wunknown-argument] syr_thread.c(258,30): error: use of undeclared identifier 'mode'; did you mean 'modf'? |
|
Please try setting |
|
Okay the last compile attempt is done, but the flags didn't seem to take effect it put a lot of warnings into the log file. Around 1.1 million lines (~56 MB), but the first lines suggest that more compile flags have been added than before. Also the libopenblas_armv8p-r0.3.27.a got generated with 5,290,190 Bytes of size (which is about the size of libopenblas.lib, non-arm version shipped with koboldcpp), which seems bigger than in the previous attempts (~500ish kb). No dll though. Had to zip the logs as they could have been a bit to big to upload. |
|
The fatal error appears to be here: which looks like a flang configuration problem (or missing include path) - that file should be part of the flang installation |
|
Okay, I got two version of flang installed. flang one is from the windows on arm verison of flang, linked in the Documentation [2. Download and install classic flang for windows on arm])(https://github.com/OpenMathLib/OpenBLAS/wiki/How-to-build-OpenBLAS-for-Windows-on-ARM64#2-download-and-install-classic-flang-for-windows-on-arm). Though I got the one from 0.3 tag on the link rather than the 0.1, though both are rather old (2021). flang-new is from precompiled LLVM tools I wonder if that may be the issue? The release notes of 0.3.27 say
|
|
Possible - you can check if one or both have an iso_fortran_env.mod , or simply try to compile with the other one. The wiki entry is older than flang-new - we actually have an open issue ticket (#3973) about updating the instructions once the flang-new from LLVM17 or newer has been confirmed to work on WoA. (Unfortunately the guy who started it eventually dropped out, and nobody else appeared to have the system environment or interest.) |
|
Yesterday I removed the flang for woa and am getting different message now, mostly a file not found. So I think it is attempting to use the flang compiler rather than flang-new from newer LLVM versions. I tried passing in the compiler via I think there may be a few things going wrong. One seems that the lib pathes are cut off
The test compile results in but for flag in $old_flags; do
f=`echo "$flag" | tr '"' ' '`
flags="$flags $f"
doneiterates over the string by words/space, so it cuts the words quoted path and removes the quotas too which later in the for each loop when -L/-l is matched, only the first pas until the first space is matched and added to the Makefile.conf I guess that would have to be handled differntly, like some kind of tokenizing or regex pattern matching? I think this is coming from the test compile where the -S flag is used too. When changing it to "/Fa" the
I tried changing the c_check to outputfile_flag="-S"
if [ "$compiler" = "CLANG" ]; then
outputfile_flag="/Fa"
fi
data=`$compiler_name $flags $outputfile_flag ctest1.c && grep globl ctest1.s | head -n 1 && rm -f ctest1.s`Still the compiler seems to be picked wrong
Is there an easy way to skip the c_check and run it with "custom tweaked" config.h and Makefile.conf? |
|
Hm, you'd have to hack Makefile.prebuild. Also the Fortran compiler is determined by f_check not c_check, normally setting FC=flang-new should be sufficient if flang-new is in your PATH. F_COMPILER should then be set by the script according to the behaviour of the compiler. |
|
Mhh I think I made a bit of a progress with a few hacks to the c_check file First I fixed the -S errors if [ "$compiler_name" = "clang-cl" ]; then
data=`$compiler_name /Fa $outputfile_flag ctest1.c && grep globl ctest1.s | head -n 1 && rm -f ctest1.s`
else
data=`$compiler_name -S $outputfile_flag ctest1.c && grep globl ctest1.s | head -n 1 && rm -f ctest1.s`
fiThe one with the CEXTRALIBS is more difficult and goes over my bash skills. But as a hack to progress further i simply hard-coded the This would need to be fixed with regex or similar to handle spaces in the -libpath flags. Another issue that appeared in the logs previously were the clang-cl doesn't have "-dumpversion" parameter. This would need to be parsed from The version for clang-cl could be parsed via Again, still didn't felt confident to do that in the Makefile.system, so I simply hard coded the two variables, since I know that I got CLANG 18 which is newer than both of 9 and 12 This compiled a lot more and the resulting libopenblas_armv8p-r0.3.27.a was now around 10.4 MB. Still no lib/dll but only a few errors left in the logs The Makefile.conf and config.h now Logs: Mostly type of errors seem to be left on the first look. The subsystem/linker errors seem to be from the c_check file, but I can't figure where the line lies who runs/causes this. Probably around the test compiles? |
|
The |
Yea, a make.inc is generated there and refreshed on every build. replacing the -c and -o with /c and /Fe fixed two of the three occurances. The first one seems to happen here no_sve=0
if [ "$architecture" = "arm64" ]; then
tmpd=$(mktemp -d 2>/dev/null || mktemp -d -t 'OBC')
tmpf="$tmpd/a.c"
printf "#include <arm_sve.h>\n\n int main(void){}\n">> "$tmpf"
args=" -march=armv8-a+sve -c -o $tmpf.o $tmpf"
no_sve=0
{
$compiler_name $flags $args >/dev/null 2>&1
} || {
args=" -Msve_intrinsics /c /Fe $tmpf.o $tmpf"
$compiler_name $flags $args #>/dev/null 2>&1
} || {
no_sve=1
}
rm -rf "$tmpd"
fiWhen i removed the I also tried removing replcing |
|
there is another |
|
(No solution for suppressing the split of the |
|
content of $link |
|
Thank you. Maybe the simplest solution would be to add something like before the part that starts with the comment "strip trailing quotes", and then set |
|
The This makes first messages disappear, still stuck at the ones. Gonna give compiling under WSL2 a try and see if I can get a dll cross-compiled that way |
|
Ok, thanks. Maybe the |
|
Also tried it without the
Just a bunch of
messages |
|
Indeed that's just the BLAS/CBLAS and internal functions from OpenBLAS, no sign of LAPACK. And no sensible information to be found for that Error -1073741569 |
|
WSL2 attempt seems to be a dead end too, at least for now. Got it set up so far and compiles for linux aarch64, but there seem to be missing the Only thing I found is that microsoft merged their first contributions to the gcc compiler to add the So I may give it a try later or see if the cmake path works better of if there is a different type of environment that's independent of w64devkit (it seems to have quite some issues, the c_check script running awfully slow in w64devkit, taking minutes before the actual compiling beings, while in wsl2 it just takes a few seconds). Or maybe there's a way to get it done withn the VS environment (Dev console) The total changes in c_check so far that improved it quite, but not fully able to build yet as stated above. The other thing that had errors and would need to be addressed is Makefile ifeq ($(C_COMPILER), CLANG)
CLANGVERSIONGTEQ9 := $(shell expr `$(CC) -dumpversion | cut -f1 -d.` \>= 9)
CLANGVERSIONGTEQ12 := $(shell expr `$(CC) -dumpversion | cut -f1 -d.` \>= 12)
endifclang-c doesn't have a -dumpversion flag and would need to parse the |
|
Thanks. It occurs to me that you could try with NOFORTRAN=1 , which should build the LAPACK component from C sources (created from the original Fortran with a modified f2c). Maybe this can work around whatever leads to the unexplained Error -1073741569 |
|
Nope, still same Error -1073741569 and stops at the same point |
|
Weird. so it seems to be something to do with the generation of make.inc after all, even though the file looked correct. Maybe it is the leading dash in the |
|
I haven't read the entire thread. Sorry if this has been discussed before. Fwiw, -1073741569 is 0xC00000FF in hexadecimal. That is the value of
Not sure if that is helpful in tracking this down. Just some wild guesses: Does adding Is there a difference if you are using the CMake build system? |
|
Right, I already found that brief explanation of the status code, but no details on what exactly could be "malformed" about it or how to find out more. The only (relevant) instance of "malformed function table" in a github issue (someone trying to port luajit to WoA) seems to suggest the function table itself may be correct but lack a valid pointer for some function ? |
|
For what it's worth: GitHub is hosting ARM64 runners (Linux and Windows) now:
I don't know if OpenMathLib has access to minutes in a Team or Enterprise Cloud plan. |
|
There also seems to be a docker image for emulating Windows on ARM on Linux x86. See, e.g., a pointer to it here. But admittedly, I never tried to use that. |
|
According to #4925 the vcpkg project appears to be able to build WoA binaries, though using cmake&ninja |
For the last 4 days I've been trying to compile the OpenBLAS library on WIndows on Arm (for Windows on Arm) using Build OpenBLAS static library with BLAS and LAPACK routines with Make.
After installing LLVM, Visual Studio and the required build tools I made some kind of progress, but I kept getting this error
using the Documentations
Build command. It's the "drivers/level2" which fail.
As far as I can tell, the "common_threads.h" is not being included inside "common.h"
After having a further look, I've seen that it's set when USE_THREAD=1 and NUM_THREADS > 1.
But even using
Still gives me the same error.
Additionally I also get lld-link errors at the begin of the compile process.
As far as I got it so far, it requires to determine the subsystem (windows or console), but from what I've seen so far this isn't required for dlls, only for executables in Windows, so I am confused. The other thing I also found while searching for it is that the cclang uses "-S" flag while clang-cl is supposed to use "-Fa" flag instead to set the subsystem.
But I can't find a how to fix that or where to change it. Complete at loss here. Any ideas?
I'm using
Any clues on how to fix some or both of these?
The text was updated successfully, but these errors were encountered: