title: Linking LAPACK, 64-bit, Visual Studio 2013
body: <p>I'm unable to compile introductory Lapack code in Visual Studio 2013 for a 64-bit platform.  Summary of what I'm trying to do:</p>
  
  <ul>
  <li>Get Lapack up and running in support of 64-bit C++ software I'm writing in Visual Studio 2013.  </li>
  <li>I'm using the same directions given at <a href="http://icl.cs.utk.edu/lapack-for-windows/lapack/#build" rel="nofollow">http://icl.cs.utk.edu/lapack-for-windows/lapack/#build</a> by following directions for using the pre-built libraries (*.dll, *.lib &amp; *.h) and referencing those in my build.</li>
  </ul>
  
  <p>Visual Studio steps I'm taking:</p>
  
  <ul>
  <li>I start a new project - picking the Visual C++ Empty Project template</li>
  <li>In project properties, I first go to Configuration Manager and create a new solution platform of x64 (copying the Win32 settings)</li>
  <li>Then for all configurations and for all platforms I point the Linker Additional Library Dependencies to where I put the prebuilt *.lib files.  I also add to the Linker => Input the libblas.lib and liblapack.lib libraries as instructed.</li>
  <li>Note 1: I'm not adding any of the Lapacke stuff yet since I don't believe the simple example program I'm trying to run will need that stuff (and adding those paths did not seem to help in earlier attempts.)</li>
  <li>Note 2: I know that the libraries I downloaded are 64-bit only - but I applied these project properties to 'all platforms' (meaning including the 32-bit platform) to demonstrate something, below...</li>
  <li>Then in Visual Studio, I added a single C++ source file 'source.cpp' with the code provided at www.cs.rochester.edu/~bh/cs400/using_lapack.html.  Here's the code</li>
  </ul>
  
  <blockquote>
    <p></p>
  </blockquote>
  
  <pre><code> #include &lt; stdio.h&gt;
  
   extern "C" void dgesv_(const int *N, const int *nrhs, double *A, const int *lda, int *ipiv, double *b, const int *ldb, int *info);
   extern "C" void dgels_(const char *trans, const int *M, const int *N, const int *nrhs, double *A, const int *lda, double *b, const int *ldb, double *work,
   const int * lwork, int *info);
  
  int main(void)
  {
      double A[9] = { 76, 27, 18, 25, 89, 60, 11, 51, 32 };
      double b[3] = { 10, 7, 43 };
  
      int N = 3;
      int nrhs = 1;
      int lda = 3;
      int ipiv[3];
      int ldb = 3;
      int info;
  
      dgesv_(&amp;N, &amp;nrhs, A, &amp;lda, ipiv, b, &amp;ldb, &amp;info);
  
      if (info == 0) /* succeed */
          printf("The solution is %lf %lf %lf\n", b[0], b[1], b[2]);
      else
          fprintf(stderr, "dgesv_ fails %d\n", info);
  
      return info;
  }
  </code></pre>
  
  <ul>
  <li>And then I try to compile this program (in either Debug or Release configuration) - for an x64 platform and get the error:</li>
  </ul>
  
  <blockquote>
    <p>error LNK2019: unresolved external symbol dgesv_ referenced in function main</p>
  </blockquote>
  
  <p>which seems to indicate that the prebuilt libraries do not contain these functions.</p>
  
  <ul>
  <li>The very odd thing is that if I change the platform to 'win32', the project compiles! (huh?)  So it's finding those libraries for the 32-bit platform.  (Btw, if I try to run the executable generated there, I get an error that a *.dll file is missing - which is not surprising given that I only downloaded the 64-bit libraries...)</li>
  </ul>
  
  <p>Also, adding an underscore before dgesv_ in the code also does not seem to work - giving me the error upon compilation:</p>
  
  <blockquote>
    <p>fatal error LNK1112: module machine type 'X86' conflicts with target machine type 'x64'</p>
  </blockquote>
  
  <p>which also tracks with some of the discussion at icl.cs.utk.edu/lapack-forum/viewtopic.php?f=12&amp;t=4260</p>
  
  <p>Again, this entire issue seems to track the discussion at <a href="http://icl.cs.utk.edu/lapack-forum/viewtopic.php?f=12&amp;t=4260" rel="nofollow">http://icl.cs.utk.edu/lapack-forum/viewtopic.php?f=12&amp;t=4260</a> and folks there seemed to indicate that building the libraries yourself with CMAKE is a solution (I'm trying that but running into issues there with it not finding the proper fortran compiler in the MinGW-W64 libraries I downloaded &lt;= that's probably appropriate for a different post!).  More importantly, in the last post of that thread, 'admin' indicated that they corrected any previous problem with these pre-built libaries and that they should work now.  So I must be doing something incorrect, right?.  Does anyone see a problem in the workflow I'm using here?</p>