Visual Studio runtime libraries are linked dynamically

[gpu]

This may be considered as a non-issue for you, but the Visual Studio runtime libraries are currently linked dynamically. This basically means that someone who wants to use the compiled CLBlast DLL may encounter an error message saying that "MSVCP140.DLL" can not be found.

I'm also not so familiar with the details, but I encountered the same problem in JCuda. A bit of websearching led to https://cmake.org/Wiki/CMake_FAQ#How_can_I_build_my_MSVC_application_with_a_static_runtime.3F . It boils down to some odd linker flag in the end, and I eventually fixed it by defining this file https://github.com/jcuda/jcuda-common/blob/master/JCudaCommon_CMake_flags.txt (which refers to https://github.com/jcuda/jcuda-common/blob/master/CMake_c_flag_overrides.cmake and https://github.com/jcuda/jcuda-common/blob/master/CMake_cxx_flag_overrides.cmake ), and including it before any project definition (this is important). For example, as in https://github.com/jcuda/jcufft/blob/master/JCufftJNI/CMakeLists.txt

Sorry, I know that things like this are somewhat annoying (i.e. distressingly non-academic), but I wanted to point it out.

[blueberry]

@CNugteren do you have any estimate on this? I am about to release Neanderthal, and would prefer to wait for this to be solved so that @gpu can release 0.7.1 of JOCLBlast, but if it is not in the near plans, it is better to know, to go with 0.7.0 anyway...

[CNugteren]

Actually, the 0.7.1 release was just made. It includes the fix suggested in this issue. I haven't tested it on a system without Visual Studio installed, but the compiled DLLs are a little bit bigger, so hopefully they now include the necessary runtime library functions.

Could you test if this is resolved or not?

[blueberry]

That is fantastic! Thanks!

[blueberry]

Unfortunately, I cannot test it because I do not have any Windows machine. I hope @gpu will test that soon.

[gpu]

I'm not sure whether I can test it today, but hopefully tomorrow. Still, I have to figure out how to test it appropriately. At home, I have installed VS2015, so the MSVCP140.DLL is lingering around somewhere on my system. (I could probably try to find and rename it, to provoke an error with the current version, and then see if the error still appears with the new version - or I can try it in my office, but have to see whether I can schedule this before the weekend)

[gpu]

I can confirm that 0.7.1 builds out-of-the-box with VS2015, and the resulting DLL does no longer have a dependency to MSVCP140.DLL according to "Dependency Walker", and I re-checked that when (temporarily) removing the MSVCP140.DLL, the sgemm sample in 0.7.0 caused an error message, but works properly in 0.7.1.
Thanks for your efforts, I'll close this one now.