search

clMathLibraries / clBLAS

a software library containing BLAS functions written in OpenCL
Apache License 2.0
839 stars 240 forks source link

Segmentation fault after linking to lib64/clAmdBlas.lib in MinGW compilation on Windows #43

Closed myurkin closed 10 years ago

myurkin commented 10 years ago

I am trying to use clAmdBlas 1.10 package on Windows 7 (64 bit) notebook with Nvidia GTX540M. I am using MinGW (with gcc 4.8.1) to compile the programs. I've noticed that there is a difference (in native 64-bit mode) between linking to clAmdBlas.lib and directly to clAmdBlas.dll (renamed into libclAmdBlas.dll.a).

If I link to clAmdBlas.dll everything is fine. If I link to clAmdBlas.lib, the compilation goes OK, but I get segmentation fault when calling clAmdBlasSetup. I have tried to run those two executables (without recompiling) on another Windows7 computer with AMD7950 GPU - had the same results. This behavior is the same both with my program and with examples from clAmdBlas package (e.g. example_saxpy.c).

Is it a designed behavior (e.g. because .lib is designed for Visual Studio and not for MinGW) or is it a bug? I have encountered such differences neither for 32-bit library nor for clAmdFft (both .lib and .dll can be used for linking, resulting in executables. which are not binary identical but produce identical results when ran).

I report a problem for rather old version of the package, because I do not see at easy way to obtain a more recent DLL for Windows.

kknox commented 10 years ago

Hi @myurkin I am not a mingw expert, but I have used it a few times in the past. The concept of an import library is somewhat foreign to gcc, so I think it is common to have to resort to some preprocessing of files to get interoperability between MSVC and mingw (clAmdBlas was compiled with MSVC). I do not think it is valid to rename a .dll into .dll.a.

Have you read the mingw documentation in this regard? http://www.mingw.org/wiki/DLL

You can find recent binary versions of clBLAS on the clBLAS releases page: https://github.com/clMathLibraries/clBLAS/releases

kknox commented 10 years ago

@myurkin Going to close this soon and assume it is resolved.

myurkin commented 10 years ago

Hi Kent,

I thought that I commented on this issue, but somehow my comment has not appeared (probably I forgot to press the final button, sorry). So here it is once again:

I've tried the clBLAS 2.2 binaries and the results are the same (linking to 64-bit .lib results in further failure, but all other variants work fine). But it seems that it is more or less designed behavior. For instance, here http://stackoverflow.com/a/7738313 it is said that 64-bit .lib can't be used by MinGW linker (while 32-bit ones - can).

Also, accidentally I realized that MinGW can link directly to .dll (probably for a long time already, see e.g. http://stackoverflow.com/a/15853231 ), so there is no need to rename it into lib*.a . I guess, now the safest way for MinGW compilation in all cases is to link to .dll directly (not using .lib at all).

The only remaining question is why linking to 64-bit .lib works for clAmdFft, but that is probably not interesting to investigate. Indeed, the issue can be considered resolved.

Thanks for your help, Maxim.