title: Linker reads library but can't find symbol within it? Unresolved External Symbol but only for Win32 and not x64
body: <h2>Background</h2>
  
  <p>I have a C astronomical library that I want to use in my C++ application.</p>
  
  <p>I've built it in Visual Studio 2012 Express in both <strong>Win32</strong> and <strong>x64</strong> configurations, and:</p>
  
  <ul>
  <li>dynamic debug (.dll)</li>
  <li>dynamic release (.dll)</li>
  <li>static debug (.lib)</li>
  <li>static release (.lib)</li>
  </ul>
  
  <p>...so that is 2 * 4 = 8 total binaries (not counting *.pdb files, etc.)</p>
  
  <p>Then I use Batch Build to build all configurations, as sometimes I need different versions and I find getting this all done at the start and with a process is better than haphazardly when it's easy to mix things up.</p>
  
  <p>Well in my C++ app, I have the same process, and link to the library based on the name. Specifically, in my project properties <strong>Linker -> Input</strong> field, I have:</p>
  
  <pre><code>SwissEphemeris_$(Platform)_$(Configuration).lib
  </code></pre>
  
  <p>...and the <strong>Additional Library Directories</strong> is properly set. Everything seems right. The library files are in the library directory.</p>
  
  <h2>Here is the trouble:</h2>
  
  <p>Out of the 8 total configurations I have, all are linking and building properly except for two:</p>
  
  <ol>
  <li>Win32 dynamic debug</li>
  <li>Win32 dynamic release</li>
  </ol>
  
  <p>For both of these configurations, the same linker error:</p>
  
  <pre><code>main.obj : error LNK2019: unresolved external symbol _swe_close referenced in function _main
  </code></pre>
  
  <p>I have tried some things to diagnose or fix, but none have worked:</p>
  
  <ol>
  <li>rebuilding the library from scratch in a new Solution/Project, ensuring no deviation between <strong>Win32</strong> and <strong>x64</strong> other than the <code>/MACHINE</code> linker flag</li>
  <li>creating a new fresh Solution/Project with nothing but a main() that called this one library function <code>swe_close()</code> in Win32 dynamic debug configuration and linked to that *.lib.</li>
  </ol>
  
  <p>The error is always the same, as shown above. I've turned on verbose linker output, and what really puzzles me is that the linker seems to successfully find and read the <code>SwissEphemeris_Win32_DynamicDebug.lib</code> file, but still cannot find the <code>swe_close()</code> symbol within it. Even when <code>dumpbin.exe</code> shows that symbol, among all the other ones I need, are in it.</p>
  
  <pre><code>1&gt;  Unused libraries:
  1&gt;    E:\Data\Code\lib\SwissEphemeris\SwissEphemeris_Win32_DynamicDebug.lib
  1&gt;    C:\Program Files (x86)\Windows Kits\8.0\lib\win8\um\x86\user32.lib
  1&gt;    C:\Program Files (x86)\Windows Kits\8.0\lib\win8\um\x86\gdi32.lib
  1&gt;    C:\Program Files (x86)\Windows Kits\8.0\lib\win8\um\x86\winspool.lib
  1&gt;    C:\Program Files (x86)\Windows Kits\8.0\lib\win8\um\x86\comdlg32.lib
  1&gt;    C:\Program Files (x86)\Windows Kits\8.0\lib\win8\um\x86\advapi32.lib
  1&gt;    C:\Program Files (x86)\Windows Kits\8.0\lib\win8\um\x86\shell32.lib
  1&gt;    C:\Program Files (x86)\Windows Kits\8.0\lib\win8\um\x86\ole32.lib
  1&gt;    C:\Program Files (x86)\Windows Kits\8.0\lib\win8\um\x86\oleaut32.lib
  1&gt;    C:\Program Files (x86)\Windows Kits\8.0\lib\win8\um\x86\uuid.lib
  1&gt;    C:\Program Files (x86)\Windows Kits\8.0\lib\win8\um\x86\odbc32.lib
  1&gt;    C:\Program Files (x86)\Windows Kits\8.0\lib\win8\um\x86\odbccp32.lib
  1&gt;    E:\Programs\VS2012\VC\lib\OLDNAMES.lib
  1&gt;  
  1&gt;main.obj : error LNK2019: unresolved external symbol _swe_close referenced in function _main
  1&gt;E:\Data\Code\test\Debug\test.exe : fatal error LNK1120: 1 unresolved externals
  ========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========
  </code></pre>
  
  <p><em>scratching head</em></p>
  
  <p>Does anyone have any idea why the linker is failing to find the symbol, and <em>ONLY</em> for Win32 dynamic debug/release, but working fine for all 6 other configurations?</p>
  
  <p>Just to be sure that the library was indeed built for Win32/X86, here is the linker command-line options from the library project's properties:</p>
  
  <p><em>(paths are slightly different than the paths above--where the linker attempts to find the library--because the library is first built to this 'bin' directory and then copied to the library directory, which is definitely happening.)</em></p>
  
  <pre><code>/OUT:"E:\Data\Code\libBuilders\SwissEphemeris\bin\SwissEphemeris_Win32_DynamicDebug.dll" 
  /MANIFEST 
  /NXCOMPAT 
  /PDB:"E:\Data\Code\libBuilders\SwissEphemeris\bin\SwissEphemeris_Win32_DynamicDebug.pdb" 
  /DYNAMICBASE 
  /IMPLIB:"E:\Data\Code\libBuilders\SwissEphemeris\bin\SwissEphemeris_Win32_DynamicDebug.lib" 
  /DEBUG 
  /DLL 
  /MACHINE:X86 
  /SAFESEH 
  /PGD:"E:\Data\Code\libBuilders\SwissEphemeris\bin\SwissEphemeris_Win32_DynamicDebug.pgd" 
  /SUBSYSTEM:CONSOLE 
  /MANIFESTUAC:"level='asInvoker' uiAccess='false'" 
  /ManifestFile:"E:\Data\Code\libBuilders\SwissEphemeris\obj\SwissEphemeris_Win32_DynamicDebug\SwissEphemeris_Win32_DynamicDebug.dll.intermediate.manifest" 
  /ERRORREPORT:PROMPT 
  /NOLOGO 
  </code></pre>
  
  <p>Output from <code>dumpbin.exe /exports</code></p>
  
  <pre><code>E:\Data\Code\lib\SwissEphemeris&gt;dumpbin /exports SwissEphemeris_Win32_DynamicDebug.dll
  Microsoft (R) COFF/PE Dumper Version 11.00.50727.1
  Copyright (C) Microsoft Corporation.  All rights reserved.
  
  
  Dump of file SwissEphemeris_Win32_DynamicDebug.dll
  
  File Type: DLL
  
    Section contains the following exports for SwissEphemeris_Win32_DynamicDebug.dll
  
      00000000 characteristics
      528041A6 time date stamp Sun Nov 10 19:32:06 2013
          0.00 version
             1 ordinal base
           131 number of functions
           131 number of names
  
      ordinal hint RVA      name
  
            1    0 00001195 _swe_azalt@40 = @ILT+400(_swe_azalt@40)
            2    1 000011FE _swe_azalt_d@28 = @ILT+505(_swe_azalt_d@28)
            3    2 000012AD _swe_azalt_rev@24 = @ILT+680(_swe_azalt_rev@24)
            4    3 00001357 _swe_azalt_rev_d@20 = @ILT+850(_swe_azalt_rev_d@20)
            5    4 0000126C _swe_calc@24 = @ILT+615(_swe_calc@24)
            6    5 000011BD _swe_calc_d@20 = @ILT+440(_swe_calc_d@20)
            7    6 0000105F _swe_calc_ut@24 = @ILT+90(_swe_calc_ut@24)
            8    7 00001235 _swe_calc_ut_d@20 = @ILT+560(_swe_calc_ut_d@20)
            9    8 00001389 _swe_close@0 = @ILT+900(_swe_close@0)
           10    9 00001212 _swe_close_d@4 = @ILT+525(_swe_close_d@4)
           ...
  </code></pre>
  
  <p>Where the DLL is defined for export in the library header file. Only <code>MAKE_DLL</code> and <code>PASCAL</code> are defined, so the only statements here that are active are the <code>#define PASCAL_CONV PASCAL</code> and the <code>#else /* 32bit DLL */</code> block.</p>
  
  <pre><code>/* DLL defines */
  #ifdef MAKE_DLL
    #if defined (PASCAL)
      #define PASCAL_CONV PASCAL 
    #else
      #define PASCAL_CONV
    #endif
    #ifdef MAKE_DLL16 /* 16bit DLL */
      /* We compiled the 16bit DLL for Windows 3.x using Borland C/C++ Ver:3.x
         and the -WD or -WDE compiler switch. */
      #define EXP16 __export 
      #define EXP32 
    #else /* 32bit DLL */
      /* To export symbols in the new DLL model of Win32, Microsoft 
         recommends the following approach */ 
      #define EXP16 
      #define EXP32  __declspec( dllexport )
    #endif
  #else 
    #define PASCAL_CONV 
    #define EXP16 
    #define EXP32 
  #endif 
  </code></pre>
  
  <p>...Then the actual function <code>swe_close()</code> declaration looks like:</p>
  
  <pre><code>ext_def( void ) swe_close(void);
  </code></pre>
  
  <p>They use a lot of macro footwork, so this resolves to:</p>
  
  <p><code>extern __declspec(dllexport) void far PASCAL swe_close();</code></p>
  
  <p>I am unfamiliar with the <code>far</code> and the <code>PASCAL</code>. Could these be interfering with anything? And why would the <strong>x64</strong> configuration work fine with this, but the <strong>Win32</strong> break?</p>