Windows Support about blasfeo HOT 48 OPEN

I'm fine with sharing as long as @giaf is ok with it. I'm using for my own purposes.

from blasfeo.

@TureganoJose sure I would be happy to include the changes (code and configuration description) in the repo to improve Windows compatibility. Thanks for the work on that!

Can you make a pull request or share a git diff or something similar with the changes you did?
Then I can go though them and merge with the repo.

from blasfeo.

The code has now been fixed to build library and examples using cmake on windows with visual studio compiler, for the GENERIC target in BLASFEO.

@TureganoJose posted some pictures to show the necessary setup steps, they can be found in here #119

from blasfeo.

In linux everything works as expected, e.g. I get from the cmake build for a shared library

~/blasfeo/build$ nm libblasfeo.so | grep dgemm_
000000000010d4b0 T blasfeo_dgemm_dn
000000000010d590 T blasfeo_dgemm_nd
00000000000fe3f0 T blasfeo_dgemm_nn
00000000000ff2a0 T blasfeo_dgemm_nt
0000000000100ef0 T blasfeo_dgemm_tn
00000000001027a0 T blasfeo_dgemm_tt
000000000012b7e0 T dgemm_

So I can't reproduce the issue on linux, and I don't have access to a window machine ATM.
I also don't have much experience with windows, so surely I can't fix this "open-loop".

At the very least, the windows support is at the point of being able to compile a static library of the GENERIC target using visual studio, with the routines needed in HPIPM and acados, which is already a good achievement given the lack of a testing machine.
I will investigate more the remaining issues once I can get back to the office and access a windows machine.

from blasfeo.

First of all, please notice that personally my experience with windows is limited, so I can not provide as much giudance as with linux.

That said, in windows you can either:

• use make (which supports both BLASFEO and BLAS APIs) and MinGW-w64 compiler (which supports any target, provided that OS in Makefile.rule is set to WINDOWS to correctly build the assembly code for the windows function calling convention), both of which you can install with e.g. the Cygwin environment;
• use cmake (that at the moment supports the BLASFEO API but not the BLAS API) and visual studio compiler (that at the moment only support the generic target);
• it should be possible to do also something with WSL (windows subsystem for linux) in windows 10, but I don't have direct experience with that, so I don't know what is the workflow there.

If you try out any of them, I would appreciate to get feedback on it :)

from blasfeo.

If some other user like e.g. @jkoendev has some experience to share, it would be great :)

from blasfeo.

i compiled acados on windows using cmake and mingw-w64 which also builds blasfeo, so it is probably similar.

I documented the procedure here:
acados/acados#411

from blasfeo.

@giaf , Where can I find how to build CMake + MSVC with the GENERIC target? What prevents using other targets?

from blasfeo.

Personally I don't have first-hand experience on windows systems using MSVC, but in that case building the GENERIC target of BLASFEO using cmake shouldn't be any different than building any other C project.

About the use of other targets than GENERIC, the issue there is that the assembly .S files are coded in the AT&T syntax, while MSVC requires the Intel syntax (while GENERIC is entirely written in C without assembly).
One work around is to use mingw-w64 to assemble the .S files into .o files, and then modify the CMakeLists.txt to have as targets the .o files instead of the .S files. In this way, MSVC will simply compile the remaining .c files and make a library out of all the .o files (regardless of whether they originate form .S or .c files). This works because the BLASFEO .S files are entirely self-contained and don't contain any call to e.g. system functions.

from blasfeo.

What about Clang?
We have Clang in Windows.

By the way, on Windows when I set SHARED_LIBS=ON it doesn generate the DLL but I don't see the .lib file to attach.
At least usually for project to use DLL you need the lib for the compilation phase.

Remark: I'm under the impression the lib files generated in the non shared libs mode are those for static linking.

from blasfeo.

I managed to build it in Windows with CMake, creating a solution for VS then you can build either, static or dynamic libraries. There was a bit of fiddling with the c code. Apparently void* is handled in a different way by gcc.

from blasfeo.

@TureganoJose , could you share your code and configuration?
I'd assume it is something @giaf will be happy about - offering Windows compatibility.

Thank You.

from blasfeo.

@giaf , This is great!

Is there a hope to have non generic as well?
Since we have GCC (MinGW) and Clang-CL on Windows.

from blasfeo.

Hi @RoyiAvital
Yes with MinGW-w64 you should be able to compile any target, while I can't say with Clang-CL because I don't have any experience with that (Clang can compile any target on linux, so there is hope).
OTOH visual studio is only limited to GENERIC target because it doesn't accept the assembly dialect used in the other BLASFEO targets.

If you want to experiment and give some feedback, it would be great :)
I don't have access to a windows machine ATM.

from blasfeo.

So no need for MSYS or Cygwin, just GCC on MinGW64 and it will work?

Which dialect of assembly do you use? Which is used by VS?

from blasfeo.

In theory you just need MinGW-w64 and cmake.
Then if you have MSYS or Cygwin you can also use the make build system, git and whatever you want like if you were in linux, if this is your usual workflow.
I tested some time ago, but again I can't do it now.

For x86 and x86_64 targets, I use AT&T syntax, while visual studio only accepts Intel syntax AFAIK.
(If the use of visual studio is necessary e.g. for inclusion in another toolchain, and if there are both MinGW-w64 and visual studio available on the system, an option is to use MinGW-w64 to assemble the .S files into windows object files, and then use visual studio to compile the remaining .c files and include all object files into a library. This would give the possibility to use any BLASFEO target in a visual studio project.)

from blasfeo.

This is what I thought. Maybe using GIT LFS we can add pre compiled object files of the assembly for Windows users?

I can try generating them and build something to automate their creation (Given it is easy to do using MinGW64).
Should I generate the S files in the Archive (For example avx/archive/) sub folders or only the parent folder (avx/)?

from blasfeo.

The issue is that I edit also the assembly files on a regular basis while developing new features.
So it would be great to have the object files automatically precompiled somewhere on the cloud, for every commit. Or alternatively to release them only once in a while attached to some specially tagged commit. @tmmsartor do you have any suggestion here?

Whatever is in any archive folder should be disregarded, as it is not compiled in the libraries.
As a guideline, only the .o files generated from .S by the make build system are needed, so in theory it is only a matter of running make static_library from the main BLASFEO folder and then collect the needed files. (All .S files are completely self-contained with e.g. no system calls, this makes it possible to compile them with MinGW-w64 and include them with visual studio.)

from blasfeo.

OK, I'm trying to compile the project on Windows using MinGW64.

I get an error no matter what target I chose:

Generic Target

cmake -G"MinGW Makefiles" -DTARGET=GENERIC ..
-- The C compiler identification is GNU 7.3.0
-- The ASM compiler identification is GNU
-- Found assembler: D:/Applications/Programming/MinGW/bin/gcc.exe
-- Check for working C compiler: D:/Applications/Programming/MinGW/bin/gcc.exe
-- Check for working C compiler: D:/Applications/Programming/MinGW/bin/gcc.exe - works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Using linear algebra: HIGH_PERFORMANCE
-- Using external BLAS: 0
-- Testing target GENERIC: compilation [failed]
Compile output:
Change Dir: C:/Users/User/BLASFeo/Build/compilerTest/GENERIC/CMakeFiles/CMakeTmp

Run Build Command(s):D:/Applications/Programming/MinGW/bin/mingw32-make.exe cmTC_08227/fast && D:/Applications/Programming/MinGW/bin/mingw32-make.exe  -f CMakeFiles\cmTC_08227.dir\build.make CMakeFiles/cmTC_08227.dir/build
mingw32-make.exe[1]: Entering directory 'C:/Users/User/BLASFeo/Build/compilerTest/GENERIC/CMakeFiles/CMakeTmp'
Building C object CMakeFiles/cmTC_08227.dir/isa_test.c.obj
D:\Applications\Programming\MinGW\bin\gcc.exe   -DLA_HIGH_PERFORMANCE -DK_MAX_STACK=300 -DUSE_C99_MATH -DEXT_DEP -DOS_WINDOWS -MT -DEXTERNAL_BLAS_NONE -O2 -fPIC     -o CMakeFiles\cmTC_08227.dir\isa_test.c.obj   -c "C:\Users\User\BLASFeo\cmake\isa_tests\isa_test.c"
cc1.exe: error: to generate dependencies you must specify either -M or -MM
mingw32-make.exe[1]: *** [CMakeFiles\cmTC_08227.dir\build.make:85: CMakeFiles/cmTC_08227.dir/isa_test.c.obj] Error 1
mingw32-make.exe[1]: Leaving directory 'C:/Users/User/BLASFeo/Build/compilerTest/GENERIC/CMakeFiles/CMakeTmp'
mingw32-make.exe: *** [Makefile:140: cmTC_08227/fast] Error 2


CMake Error at cmake/TestSingleTarget.cmake:25 (message):
  Unable to compile for target GENERIC
Call Stack (most recent call first):
  CMakeLists.txt:308 (TestSingleTarget)


-- Configuring incomplete, errors occurred!
See also "C:/Users/User/BLASFeo/Build/CMakeFiles/CMakeOutput.log".

Automatic Target

cmake -G"MinGW Makefiles" -DTARGET=X64_AUTOMATIC ..
-- The C compiler identification is GNU 7.3.0
-- The ASM compiler identification is GNU
-- Found assembler: D:/Applications/Programming/MinGW/bin/gcc.exe
-- Check for working C compiler: D:/Applications/Programming/MinGW/bin/gcc.exe
-- Check for working C compiler: D:/Applications/Programming/MinGW/bin/gcc.exe - works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Using linear algebra: HIGH_PERFORMANCE
-- Using external BLAS: 0
-- Testing target X64_INTEL_HASWELL: compilation [failed]
-- Testing target X64_AMD_BULLDOZER: compilation [failed]
-- Testing target X64_INTEL_SANDY_BRIDGE: compilation [failed]
-- Testing target X64_INTEL_CORE: compilation [failed]
-- Testing target GENERIC: compilation [failed]
CMake Error at cmake/X64AutomaticTargetSelection.cmake:31 (message):
  Unable to identify a target to use.  Please select one manually.
Call Stack (most recent call first):
  CMakeLists.txt:304 (X64AutomaticTargetSelection)

Intel Core Target

cmake -G"MinGW Makefiles" -DTARGET=X64_INTEL_CORE ..
-- The C compiler identification is GNU 7.3.0
-- The ASM compiler identification is GNU
-- Found assembler: D:/Applications/Programming/MinGW/bin/gcc.exe
-- Check for working C compiler: D:/Applications/Programming/MinGW/bin/gcc.exe
-- Check for working C compiler: D:/Applications/Programming/MinGW/bin/gcc.exe - works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Using linear algebra: HIGH_PERFORMANCE
-- Using external BLAS: 0
-- Testing target X64_INTEL_CORE: compilation [failed]
Compile output:
Change Dir: C:/Users/User/BLASFeo/Build/compilerTest/X64_INTEL_CORE/CMakeFiles/CMakeTmp

Run Build Command(s):D:/Applications/Programming/MinGW/bin/mingw32-make.exe cmTC_f5e5d/fast && D:/Applications/Programming/MinGW/bin/mingw32-make.exe  -f CMakeFiles\cmTC_f5e5d.dir\build.make CMakeFiles/cmTC_f5e5d.dir/build
mingw32-make.exe[1]: Entering directory 'C:/Users/User/BLASFeo/Build/compilerTest/X64_INTEL_CORE/CMakeFiles/CMakeTmp'
Building C object CMakeFiles/cmTC_f5e5d.dir/isa_test.c.obj
D:\Applications\Programming\MinGW\bin\gcc.exe   -DLA_HIGH_PERFORMANCE -DK_MAX_STACK=300 -DUSE_C99_MATH -DEXT_DEP -DOS_WINDOWS -MT -DEXTERNAL_BLAS_NONE -O2 -fPIC -m64 -msse3 -DTEST_SSE3   -o CMakeFiles\cmTC_f5e5d.dir\isa_test.c.obj   -c "C:\Users\User\BLASFeo\cmake\isa_tests\isa_test.c"
cc1.exe: error: to generate dependencies you must specify either -M or -MM
mingw32-make.exe[1]: *** [CMakeFiles\cmTC_f5e5d.dir\build.make:85: CMakeFiles/cmTC_f5e5d.dir/isa_test.c.obj] Error 1
mingw32-make.exe[1]: Leaving directory 'C:/Users/User/BLASFeo/Build/compilerTest/X64_INTEL_CORE/CMakeFiles/CMakeTmp'
mingw32-make.exe: *** [Makefile:140: cmTC_f5e5d/fast] Error 2


CMake Error at cmake/TestSingleTarget.cmake:25 (message):
  Unable to compile for target X64_INTEL_CORE
Call Stack (most recent call first):
  CMakeLists.txt:308 (TestSingleTarget)


-- Configuring incomplete, errors occurred!
See also "C:/Users/User/BLASFeo/Build/CMakeFiles/CMakeOutput.log".

This is the log file if you're interested:
CMakeOutput.log

from blasfeo.

Hi @RoyiAvital
By looking at the CFLAGS above, I notice the flag -MT which is not one I set, nor I can reproduce when I run the command on my linux PC. And it seems to be related to the error message somehow
https://gcc.gnu.org/onlinedocs/gcc/Preprocessor-Options.html
I guess this flag comes from cmake for the target compiler, or something like that.

In this regard, I also notice that the compiler is mingw32.
Now I don't recall exactly, but I seem to remember that there was some issue with that (I think related to 32-bitness, but anyway still issues), while the compiler MinGW-w64 (which is a different project) used to work.
This is the best hint I can give you now to find the issue.

from blasfeo.

@giaf , You're the one setting the -MT flag:

if(${CMAKE_HOST_SYSTEM_NAME} MATCHES "Windows")
	set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -DOS_WINDOWS -MT")
	set(CMAKE_ASM_FLAGS "${CMAKE_ASM_FLAGS} -DOS_WINDOWS")
endif()

Probably to use the static run time.

The compile is MinGW64.
I use this distribution (Works perfectly on other projects) - https://nuwen.net/mingw.html.

By the way, even when I remove it I get:

Building ASM object CMakeFiles/cmTC_8b366.dir/TEST_SSE3.S.obj
D:\Applications\Programming\MinGW\bin\gcc.exe   -DTEST_SSE3   -o CMakeFiles\cmTC_8b366.dir\TEST_SSE3.S.obj -c "C:\Users\User\BLASFeo\cmake\isa_tests\TEST_SSE3.S"
Linking C executable cmTC_8b366.exe
D:\Applications\Programming\CMake\bin\cmake.exe -E cmake_link_script CMakeFiles\cmTC_8b366.dir\link.txt --verbose=1
D:\Applications\Programming\CMake\bin\cmake.exe -E rm -f CMakeFiles\cmTC_8b366.dir/objects.a
D:\Applications\Programming\MinGW\bin\ar.exe cr CMakeFiles\cmTC_8b366.dir/objects.a @CMakeFiles\cmTC_8b366.dir\objects1.rsp
D:\Applications\Programming\MinGW\bin\gcc.exe  -DLA_HIGH_PERFORMANCE -DK_MAX_STACK=300 -DUSE_C99_MATH -DEXT_DEP -DEXTERNAL_BLAS_NONE -O2 -fPIC -m64 -msse3 -DTEST_SSE3    -Wl,--whole-archive CMakeFiles\cmTC_8b366.dir/objects.a -Wl,--no-whole-archive  -o cmTC_8b366.exe -Wl,--out-implib,libcmTC_8b366.dll.a -Wl,--major-image-version,0,--minor-image-version,0 @CMakeFiles\cmTC_8b366.dir\linklibs.rsp
CMakeFiles\cmTC_8b366.dir/objects.a(isa_test.c.obj):isa_test.c:(.text.startup+0xa): undefined reference to `test_sse3'
collect2.exe: error: ld returned 1 exit status
mingw32-make.exe[1]: *** [CMakeFiles\cmTC_8b366.dir\build.make:115: cmTC_8b366.exe] Error 1

from blasfeo.

OK,
I solved it by changing:

if(${CMAKE_HOST_SYSTEM_NAME} MATCHES "Windows")
	set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -DOS_WINDOWS -MT")
	set(CMAKE_ASM_FLAGS "${CMAKE_ASM_FLAGS} -DOS_WINDOWS")
endif()

Into:

if(${CMAKE_HOST_SYSTEM_NAME} MATCHES "Windows")
	set(CMAKE_C_FLAGS "${CMAKE_C_FLAGS} -DOS_WINDOWS")
	set(CMAKE_ASM_FLAGS "${CMAKE_ASM_FLAGS} -DOS_WINDOWS")
endif()

By the way, no need for the -MT flag.
New versions of CMAKE will ignore it anyway on MSVC.

The question now is what difference does it make to have DOS_WINDOWS compared to DOS_LINUX or DOS_MAC? Does it have any effect on the code itself?

By the way, GCC on Windows has issues with AVX code.
See msys2/MSYS2-packages#1209 (comment).

from blasfeo.

I don't have the flag -MT in the CMakeLists.txt in the current version of BLASFEO
https://github.com/giaf/blasfeo/blob/master/CMakeLists.txt#L273
and I couldn't find it with blame on older versions too.

from blasfeo.

I'm sorry, so it might be me who has done it before and forgot.

Sorry for that.

from blasfeo.

What is the difference between the two codes in the fix besides the -MT ?

Yes -DOS_WINDOWS vs LINUX or MAC also affects the code, as the function calling convention is different for the three. So for assembly functions, the correct function calling convention has to be used by hand, see e.g.
https://github.com/giaf/blasfeo/blob/master/cmake/isa_tests/TEST_SSE3.S
This applies to all .S files.
Additionally, some system functions are different in the different systems, so the correct one has to be picked up, e.g.
https://github.com/giaf/blasfeo/blob/master/auxiliary/blasfeo_stdlib.c

from blasfeo.

I think I just ran cmake -G"MinGW Makefiles" -DBUILD_SHARED_LIBS=OFF -DTARGET=X64_INTEL_CORE -DBLASFEO_TESTING=OFF -DBLASFEO_BENCHMARKS=OFF -DBLASFEO_EXAMPLES=OFF .. and it worked.

I chose X64_INTEL_CORE since I'm not sure if AVX2 will work on Windows with GCC as I linked above.

I think the best policy is to make Clang-CL support on Windows.

from blasfeo.

In BLASFEO memory alignment is handled explicitly, so I think there shouldn't be issues in that regards.
But can give it a try.

Actually I just fixed some remaining alignments which may have created issues with visual studio compiler for non-GENERIC targets.
29329ec

from blasfeo.

Could you make a new release?
Currently I'm on 0.1.1.

from blasfeo.

Yes once all of this is fixed I can make a release, also because I'm planning some change which shouldn't get into it.

from blasfeo.

I am working on a Pull Request to fix things.
Please wait for me. I'd be honored to contribute here.

from blasfeo.

Ok then, thanks a lot :)

from blasfeo.

Could you give me permission for the Wiki?
I would like to write about compilation on Windows. So others will have it...

By the way, I think it is good to let anyone to edit the Wiki.
Users will be able to write there some information about their usage which might be valuable to others.

from blasfeo.

We have the wiki source on a gitlab private repo on the uni server.
So either you send me the windows installation instructions in a plain text file and I add them here
https://blasfeo.syscop.de/docs/install/
or I could give you access to that repo but I need your email address to create an user.

from blasfeo.

In any case, you can send me stuff via email, my address should be on the licence of all sources.

from blasfeo.

I meant the Wiki of this repository - https://github.com/giaf/blasfeo/wiki.

from blasfeo.

Yes but there there is only a link to the wiki on our server.

from blasfeo.

I will add a new page (If you give me permission).
It will be MarkDown so you'll be able to take what you want to your official website.

By the way, I'd give anyone permission to edit the Wiki.
That way it might gather a lot of information from users which is valuable.

from blasfeo.

Ok everyone should have permission now.

from blasfeo.

Great.
I added a short guide BLASFEO - Compilation on Windows.

I guess Windows is the only system all 3 compilers are available on :-).

from blasfeo.

OK, We do compile the files but something is wrong (I am working with your latest commit - https://github.com/giaf/blasfeo/tree/windows_support).

On Windows using MSVC I do:

cmake -G"Visual Studio 15 2017 Win64" -DBLAS_API=ON -FORTRAN_BLAS_API=ON -DBUILD_SHARED_LIBS=ON -DTARGET=GENERIC -DBLASFEO_EXAMPLES=OFF ..

As I want access to dgemm_.

The output DLL contains no functions! Namely something is wrong.
Moreover, in 0.1.1 it used to generate (Correctly) the DLL and the stub Lib file while now only the DLL (Strange).

I tried:

cmake -G"Visual Studio 15 2017 Win64" -DBLAS_API=ON -FORTRAN_BLAS_API=ON -DBUILD_SHARED_LIBS=OFF -DTARGET=GENERIC -DBLASFEO_EXAMPLES=OFF ..

To try the static library.
Yet when I link it to my project it still doesn't find any reference to a function dgemm_ on the link time.

This is the result of the objects embedded in the file:

lib /LIST blasfeo.lib
Microsoft (R) Library Manager Version 14.16.27039.0
Copyright (C) Microsoft Corporation.  All rights reserved.

blasfeo.dir\Release\blasfeo_processor_features.obj
blasfeo.dir\Release\blasfeo_stdlib.obj
blasfeo.dir\Release\d_aux_lib4.obj
blasfeo.dir\Release\m_aux_lib44.obj
blasfeo.dir\Release\s_aux_lib4.obj
blasfeo.dir\Release\kernel_daxpy_lib.obj
blasfeo.dir\Release\kernel_ddot_lib.obj
blasfeo.dir\Release\kernel_dgecp_lib4.obj
blasfeo.dir\Release\kernel_dgemm_4x4_lib4.obj
blasfeo.dir\Release\kernel_dgemm_diag_lib4.obj
blasfeo.dir\Release\kernel_dgemv_4_lib4.obj
blasfeo.dir\Release\kernel_dgeqrf_4_lib4.obj
blasfeo.dir\Release\kernel_dgetr_lib4.obj
blasfeo.dir\Release\kernel_dgetrf_pivot_lib4.obj
blasfeo.dir\Release\kernel_dpack_lib4.obj
blasfeo.dir\Release\kernel_dsymv_4_lib4.obj
blasfeo.dir\Release\kernel_saxpy_lib.obj
blasfeo.dir\Release\kernel_sdot_lib.obj
blasfeo.dir\Release\kernel_sgecp_lib4.obj
blasfeo.dir\Release\kernel_sgemm_4x4_lib4.obj
blasfeo.dir\Release\kernel_sgemm_diag_lib4.obj
blasfeo.dir\Release\kernel_sgemv_4_lib4.obj
blasfeo.dir\Release\kernel_sgetr_lib4.obj
blasfeo.dir\Release\kernel_sgetrf_pivot_lib4.obj
blasfeo.dir\Release\kernel_spack_lib4.obj
blasfeo.dir\Release\kernel_ssymv_4_lib4.obj
blasfeo.dir\Release\kernel_align_generic.obj
blasfeo.dir\Release\d_blas1_lib4.obj
blasfeo.dir\Release\d_blas2_diag_lib.obj
blasfeo.dir\Release\d_blas2_lib4.obj
blasfeo.dir\Release\d_blas3_diag_lib4.obj
blasfeo.dir\Release\d_blas3_lib4.obj
blasfeo.dir\Release\d_lapack_lib4.obj
blasfeo.dir\Release\s_blas1_lib4.obj
blasfeo.dir\Release\s_blas2_diag_lib.obj
blasfeo.dir\Release\s_blas2_lib4.obj
blasfeo.dir\Release\s_blas3_diag_lib4.obj
blasfeo.dir\Release\s_blas3_lib4.obj
blasfeo.dir\Release\s_lapack_lib4.obj
blasfeo.dir\Release\dcopy.obj
blasfeo.dir\Release\daxpy.obj
blasfeo.dir\Release\ddot.obj
blasfeo.dir\Release\dgemm.obj
blasfeo.dir\Release\dsyrk.obj
blasfeo.dir\Release\dtrmm.obj
blasfeo.dir\Release\dtrsm.obj
blasfeo.dir\Release\dgesv.obj
blasfeo.dir\Release\dgetrf.obj
blasfeo.dir\Release\dgetrf_np.obj
blasfeo.dir\Release\dgetrs.obj
blasfeo.dir\Release\dlaswp.obj
blasfeo.dir\Release\dposv.obj
blasfeo.dir\Release\dpotrf.obj
blasfeo.dir\Release\dpotrs.obj
blasfeo.dir\Release\dtrtrs.obj
blasfeo.dir\Release\saxpy.obj
blasfeo.dir\Release\sdot.obj
blasfeo.dir\Release\sgemm.obj
blasfeo.dir\Release\strsm.obj
blasfeo.dir\Release\d_aux_ext_dep_lib.obj
blasfeo.dir\Release\d_aux_ext_dep_lib4.obj
blasfeo.dir\Release\i_aux_ext_dep_lib.obj
blasfeo.dir\Release\s_aux_ext_dep_lib.obj
blasfeo.dir\Release\s_aux_ext_dep_lib4.obj
blasfeo.dir\Release\timing.obj
blasfeo.dir\Release\v_aux_ext_dep_lib.obj

When trying to link I get:

error LNK2019: unresolved external symbol dgemm_ referenced in function MyFunction
fatal error LNK1120: 1 unresolved externals

I tried also with MinGW64. The static file yields the same result as above. The dynamic library generation fails.

Any idea?

from blasfeo.

No idea, and it shouldn't be related to the changes we did for windows.

from blasfeo.

It seems you don't expose the functions correctly for Windows. In the DLL nothing is exposed hence nothing is linked and for the static one, even with the FORTRAN flags the FORTRAN naming doesn't work.

from blasfeo.

If you try to call standard BLAS routines from windows, there may be some mess with names due to fortran name mangling
https://kaba.hilvi.org/homepage/blog/lapack_blas.htm
For now only names in the form dgemm_ are exported, others are not handled yet.

from blasfeo.

I am saying that dgemm_ isn't exported even when I use the FORTRAN flag (Or even even if I'm not).

Something is wrong with the export of functions on Windows as the DLL compiled has no functions in it as well.

I think that on Linux by default any function is exported in Shared Library while on Windows none.
So in Windows you need to explicitly export it, I think.

from blasfeo.

There are 2 unrelated (???) problem in Windows.

Export of Function in a DLL

In order to make functions exposed in a DLL in Windows they need to be decorated.
See Exporting Functions from a DLL with dllexport.
Windows, as opposed to Linux, by default doesn't expose any function in a DLL unless marked.

FORTRAN API Doesn't Work on Windows

For some reason when compiling the objects on Windows even if the -FORTRAN_BLAS_AP flag is defined functions are exported in their blasfeo_<funName> form and not i their BLAS naming.

from blasfeo.

Hi @RoyiAvital
yes I got that.
About issue 1), I added "open-loop" this like in the cmake
https://github.com/giaf/blasfeo/blob/master/CMakeLists.txt#L276
but I couldn't test it.
About issue 2) my code snippet above was meant to prove that in linux it does work and the correct symbol dgemm_ is present in the shared library generated by cmake.
If I can not reproduce the issue because I don't have a window machine ATM, I can't do anything about.
But I would be happy to include the fix if you have an idea about what could be wrong.

I added a travis test to build BLASFEO in windows using visual studio and run an example (using the BLASFEO API).
At the very least, this minimal example will ensure that from now on there will be support for the static library using visual studio on windows.
For more that that, I'll need access to a windows machine which I don't have ATM.

from blasfeo.

1. Export of Functions
   I will give this a try to see if it works and the DLL indeed exports the functions

2. FORTRAN API
   I tried to understand what's the issue. Something in the flags for renaming doesn't work for Windows.

from blasfeo.

For what it's worth, I made an first pass at defining a vcpkg package for blasfeo:

https://github.com/ThijsWithaar/vcpkg/tree/blasfeo
https://github.com/ThijsWithaar/blasfeo/tree/msvc-nasm

Those two use gcc from msys as assembler and MSVC for the .c compilation.
In order to make that work, blasfeo's cmake is adjusted.

The advantage of this is that for the user, vcpkg takes care of setting everything up.
The uses of add_custom_command to call the gcc-assembler as part of the MSVC build process is not so nice.

Any thoughts, feedback?

from blasfeo.