Lapack linking problem Visual Studio 2010 x64 (again)

[kenfast]

I am trying to build the simple example program referenced at
http://icl.cs.utk.edu/lapack-for-windows/lapack/ #Part 2...Visual Studio

I have downloaded the prebuilt lib and dll files for Windows x64 and MinGW from the same URL.
I also have the MinGW dlls that I need.

Following the instructions and trying to build the solution I get a link error as follows:

1>------ Rebuild All started: Project: using_lapack, Configuration: Debug x64 ------
1> using_lapack.cc
1>using_lapack.obj : error LNK2019: unresolved external symbol dgesv_ referenced in function main
1>D:\Tools\PTAM\lapack\x64\Debug\using_lapack.exe : fatal error LNK1120: 1 unresolved externals
========== Rebuild All: 0 succeeded, 1 failed, 0 skipped ==========

I have found a number of other postings of this problem, but no solutions.
(see http://icl.cs.utk.edu/lapack-forum/viewtopic.php?f=12&t=3372)

When I look inside the liblapack.lib file I see references to dgesv
(from Bash shell, with other dgesv* results removed)
$ strings liblapack.lib | grep -i dgesv
__imp__dgesv_
_dgesv_
__imp__dgesv_
_dgesv_
_dgesv_

These show a decoration with preceding and trailing underscores.

In the DLL this gives
$strings liblapack.dll | grep dgesv
dgesv_
dgesv.f
dgesv_

I am not familiar enough with name mangling to know whether this is supposed to be correct or not.

Oddly enough, the project will link successfully when set to a 32bit configuration instead of 64bit. (It does not run successfully, probably because the DLL is a 64bit version.)

I am surprised that a seemingly "typical" configuration of Visual Studio 2010 and Windows x64 does not work correctly.

I tried building my own Lapack and Blas libraries using the CMake and MinGW approach. That was also unsuccessful for my configuration. (Long story, not for this forum.) Again surprising.

Any help would be appreciated - by myself and a number of others who have posted similar questions over the past few years.

[illur666]

I have the same problem. If you found a solution please post.

[demonskull]

Hi kenfast,

I encountered the same problem, so, thanks to your post, I changed degesv_ to _degesv_. Now the unresolved external error is gone, but it's been subtituted by this other:

liblapack.lib(liblapack.dll) : fatal error LNK1112: module machine type 'X86' conflicts with target machine type 'x64'

I have made sure that I am using the 64bit version of the dll and lib files, but to no avail.

Any tips anybody?

Demon

[demonskull]

Hi kenfast,

I encountered the same problem, so, thanks to your post, I changed degesv_ to _degesv_. Now the unresolved external error is gone, but it's been subtituted by this other:

liblapack.lib(liblapack.dll) : fatal error LNK1112: module machine type 'X86' conflicts with target machine type 'x64'

I have made sure that I am using the 64bit version of the dll and lib files, but to no avail.

Any tips anybody?

Demon

[demonskull]

Well, I finally made it!

I couldn't solve the problems I was having with the lib and dlls that I downloaded from here:
http://icl.cs.utk.edu/lapack-for-windows/lapack/#libraries_mingw

So I decided to compile them myself, following the instructions given in here:
http://icl.cs.utk.edu/lapack-for-windows/lapack/#build
section: "Build Instructions to create LAPACK 3.4.1 dll for Windows with MinGW"

I used mingw64, the 64-bit version of MinGW, and Visual Studio. I had a bit of trouble with the
VCVARSAMD64 variable in Cmake, until I realised what it meant: the path to the VS bat file
that sets the environment variables, so that the lib files can be compiled. I set it to:
C:/Program Files (x86)/Microsoft Visual Studio 11.0/VC/bin/vcvars32.bat

After that, I compiled the lib and dlls with mingw32-make (from the mingw64/bin folder)
and used them in VS without a problem.

I hope that helps

[dibyendumajumdar]

Hi,

I too had problems with the 64-bit files published at:
http://icl.cs.utk.edu/lapack-for-windows/lapack/#libraries_mingw
I was getting link errors for all the fortran functions.

The 32-bit dlls worked fine, however.

I decided to build the 64-bit versions myself - using mingw64.

I had the same error mentioned above - i.e. cmake was unable to find VCVARSAMD64. I had to manually set it to:
C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin\x86_amd64.bat

Note: This is from Visual Studio 2013 Express.

The generated DLLs and LIB files worked. Hope this helps.

Regards

[admin]

Hi, sorry for the late answer, and thank you to all of you for your suggestions.
Indeed there was a problem with those prebuilt x64 libs due to CMAKE using vcvars32.bat instead of x86_amd64.bat.
To force the CMAKE to use the good configuration, a work-around is to add the variable CMAKE_SIZEOF_VOID_P and set it to 8 (string), this will force CMAKE to create the VCVARSAMD64 variable.

LAPACK 3.5.0 was just released and I regenerated all the Mingw libraries (Win32 and x64) for this release.
You should be able to use the prebuilt libraries without any problem. My VS Example project compiles fine under Visual Studio - no mor undefined reference.
http://icl.cs.utk.edu/lapack-for-window ... #libraries

Feedback appreciated!
Again thank you all for you support.
Julie

[admin]

Windows built with Mingw libraries are available for LAPACK 3.7.0 both in 32bits and 64 bits
See http://icl.cs.utk.edu/lapack-for-window ... index.html
Julie

[GIBBOGLE]

I just downloaded the x64 libraries from here:
http://icl.cs.utk.edu/lapack-for-window ... #libraries
and followed the instructions to build lapack_tut.c with MS Visual Studio 10 (x64) - adding 'extern "C"' etc.

This gives compiler errors:

1>lapack_tut.c(3): error C2059: syntax error : 'string'
1>lapack_tut.c(6): error C2059: syntax error : 'string'
1>lapack_tut.c(26): warning C4013: 'dgesv_' undefined; assuming extern returning int

Obviously C doesn't like to see "C" there. Changing the name of the source file to lapack_tut.cpp fixes the compiler errors, but now the build fails with the error that I've seen reported many times:

error LNK2001: unresolved external symbol dgesv_

I also tried building with gcc, with the same results.

It seems that the instructions given on the above site are wrong, possibly incomplete. Surely somebody in the ICL team knows this, and in that case the instructions should be corrected, or the claim that the libraries can be used to build the example with MS Visual Studio should be removed. I'm sure I'm not the only person who has wasted a lot of time on this.

Thanks, Gib