title: DLL silently ignored even though the library links
body: <p>I'm using a third part DLL that I've used successfully for ages. Now the linker links the dll lib without complaint but the exe doesn't load the dll.</p>
  <p>I recently upgraded from the 32 bit to 64 bit cygwin.
  I'm doing a mingw cross compile to 32 bits.
  I'm trying to use the FTDI USB interface FTD2XX dll.</p>
  <p>I have the version 2.04.06 FTD2XX lib, .h, and dll.
  I had been using that dll successfully for ages but with older versions of cygwin and mingw.
  Recently upgraded to cygwin64.</p>
  <p>The app appears to link with the FTD2XX.lib without complaint.
  But when I run the app it doesn't seem to look for or load the FTD2XX.dll.
  The app runs but crashes as soon as it tries to call something in FTD2XX dll.</p>
  <p>I created a simple hello_dll.dll for side by side test. That works.
  The app.c does calls on both hello_dll.dll and ftd2xx.dll.
  Is starts without complain, successfully calls function in hello_dll, and then it crashes on a call to ft2xx.dll.</p>
  <p>(I renamed the lib to ftd2xx_2.04.06 to distinguish them from other versions I have. Newer versions don't work any better.)</p>
  <p>Link with -verbose gives:</p>
  <pre><code>i686-w64-mingw32-gcc -Wall -m32 -g -O2 -c -I . -o app.o app.c
  i686-w64-mingw32-gcc -Wall -m32 -o app.exe app.o -Wl,-verbose -L. -lhello_dll -lftd2xx_2.04.06
  GNU ld (GNU Binutils) 2.34.50.20200227
    Supported emulations:
     i386pe
  using internal linker script:
  
  &lt;snip&gt;
  
  /usr/lib/gcc/i686-w64-mingw32/9.2.0/../../../../i686-w64-mingw32/bin/ld: mode i386pe
  attempt to open /usr/i686-w64-mingw32/sys-root/mingw/lib/../lib/crt2.o succeeded
  /usr/i686-w64-mingw32/sys-root/mingw/lib/../lib/crt2.o
  attempt to open /usr/lib/gcc/i686-w64-mingw32/9.2.0/crtbegin.o succeeded
  /usr/lib/gcc/i686-w64-mingw32/9.2.0/crtbegin.o
  attempt to open app.o succeeded
  app.o
  
  &lt;snip&gt;
  
  attempt to open ./hello_dll.lib succeeded
  ./hello_dll.lib
  (./hello_dll.lib)d000001.o
  (./hello_dll.lib)d000000.o
  (./hello_dll.lib)d000002.o
  
  &lt;snip&gt;
  
  attempt to open ./ftd2xx_2.04.06.lib succeeded
  ./ftd2xx_2.04.06.lib
  (./ftd2xx_2.04.06.lib)FTD2XX.dll
  (./ftd2xx_2.04.06.lib)FTD2XX.dll
  (./ftd2xx_2.04.06.lib)FTD2XX.dll
  (./ftd2xx_2.04.06.lib)FTD2XX.dll
  </code></pre>
  <p>::::::::::::::::::::::::::::</p>
  <p>I obtained a 32 bit compatible version of gdb. When I run gdb:</p>
  <pre><code>GNU gdb (GDB) 7.7.50.20140303-cvs
  &lt;snip&gt;
  This GDB was configured as &quot;i686-pc-mingw32&quot;.
  &lt;snip&gt;
  (gdb) break main
  (gdb) Breakpoint 1 at 0x40267b: file app.c, line 28.
  (gdb) run
  (gdb) Starting program: C:\_d\aaa\pd\src\dll\pathological\app.exe
  [New Thread 1428.0x2528]
  
  Breakpoint 1, main (argc=1, argv=0x9b2f70) at app.c:28
  28              dostuff();
  
  (gdb) info share
  (gdb) From        To          Syms Read   Shared Object Library
  0x774e0000  0x77644ccc  Yes (*)     C:\Windows\SysWOW64\ntdll.dll
  0x753d0000  0x754cadec  Yes (*)     C:\Windows\syswow64\kernel32.dll
  0x75ea1000  0x75ee6a3a  Yes (*)     C:\Windows\syswow64\KernelBase.dll
  0x64081000  0x6408a1d8  Yes         C:\_d\aaa\pd\src\dll\pathological\hello_dll.dll
  0x75041000  0x750eb2c4  Yes (*)     C:\Windows\syswow64\msvcrt.dll
  (*): Shared library is missing debugging information.
  (gdb) A debugging session is active.
  
  (gdb) c
  Continuing.
  Hello dll.             &lt;--- The function in hello_dll.dll prints this.
  
  
  Program received signal SIGSEGV, Segmentation fault.
  0x8000004c in ?? ()                        &lt;----- call to FT_GetLibraryVersion()
  
  (gdb) bt
  #0  0x8000004c in ?? ()
  #1  0x0040158e in dostuff () at app.c:49
  #2  0x00402680 in main (argc=1, argv=0x8e2f70) at app.c:28
  (gdb)
  </code></pre>
  <p>It links with the lib without complaint but when I run the exe it (silently) doesn't load the dll.</p>
  <p>Anybody have any ideas? Is there some linker control that I am missing? Are there other diagnostic or debug tools to dig into this further?</p>
  <p>:::::::::::::::::::::::</p>
  <p>edit 7/11/20</p>
  <p>I'll post some code. (If I know how. I'm new here.)</p>
  <p>It should be shown in the &quot;info share&quot;, but it isn't, as you can see above.</p>
  <p>I'm suspecting name decoration. Objdump -x of the .exe shows an entry for FTD2XX.dll in the Import Tables. But it doesn't show any vma or bound name under it. I suspect that at program load the loader sees no vma/name and decides it doesn't really need to load the dll.</p>
  <p>There is an import table in .idata at 0x406000</p>
  <pre><code>&lt;snip&gt;
  
  The Import Tables (interpreted .idata section contents)
   vma:            Hint    Time      Forward  DLL       First
                   Table   Stamp     Chain    Name      Thunk
   00006000   0000607c 00000000 00000000 00006218 0000614c
  
      DLL Name: FTD2XX.dll
      vma:  Hint/Ord Member-Name Bound-To
                                                        &lt;----- empty?
  
   00006014   00006080 00000000 00000000 000064f8 00006150
  
      DLL Name: hello_dll.dll
      vma:  Hint/Ord Member-Name Bound-To
      6224        1  hello_dll
  
   00006028   00006088 00000000 00000000 00006554 00006158
  
      DLL Name: KERNEL32.dll
      vma:  Hint/Ord Member-Name Bound-To
      6230      277  DeleteCriticalSection
      6248      310  EnterCriticalSection
  
  &lt;snip&gt;
  </code></pre>
  <p>:::::::::::::::::::::::::::::::::::::::::::::</p>
  <p>edit 2, 7/11/20</p>
  <p>This is the program that calls functions in the DLLs.</p>
  <pre><code>/* app.c
  
     Demonstrates using the function imported from the DLL.
  */
  
  // 200708 pathological case. Based on the simple hello_dll.
  
  //#include &lt;stdlib.h&gt;
  // for sleep
  #include &lt;unistd.h&gt;
  #include &lt;stdio.h&gt;
  // for dword
  #include &lt;windef.h&gt;
  // for lpoverlapped
  #include &lt;minwinbase.h&gt;
  
  #include &quot;hello_dll.h&quot;
  // My legacy app, and really all others too, use 2.04.06.h
  #include &quot;ftd2xx_2.04.06.h&quot;
  //#include &quot;ftd2xx_2.02.04.h&quot;
  
  ///////////////////////////
  
  void dostuff( void );
  void call_ft_listdevices( void );
  
  ///////////////////////////
  
  int main(int argc, char** argv)
  {
      FT_STATUS status;
      DWORD libver;
  
      //dostuff();
  
      printf( &quot;Calling hello_dll():\n&quot; );
      fflush( stdout );
      hello_dll();
      fflush( stdout );
      printf( &quot;Back from hello_dll()\n&quot; );
      fflush( stdout );
  
      sleep( 1 );
  
      printf( &quot;Calling FT_GetLibraryVersion().\n&quot; );
      fflush( stdout );
  
      status = FT_GetLibraryVersion( &amp;libver );
      if( status == FT_OK ){
          printf( &quot;FTD2XX library version 0x%lx\n&quot;, libver );
          fflush( stdout );
      }
      else{
          printf( &quot;Error reading FTD2XX library version.\n&quot; );
          fflush( stdout );
      }
  
      // 200710 Adding call to different ft function did
      // not result in entries in the import table.
      //call_ft_listdevices( );
  
      return 0;
  }
  </code></pre>
  <p>I don't think there is a need to include the code for my hello_dll. It works.</p>
  <p>I have three versions of the FTD2XX. I'm pretty careful about tracking versions. Plus, when one is beating one's head against the wall, double checking the versions appeals early on as a way to end the pain.</p>
  <p>I found a surprise copy of FTD2XX.dll. It's in c:/Windows/SysWOW64. It is the oldest of the three versions I have. Versions of my app that were compiled before this problem started run correctly using that dll in that place.</p>