[GHC] #7097: linker fails to load package with binding to foreign library

[GHC]

#7097: linker fails to load package with binding to foreign library
----------------------------------+-----------------------------------------
    Reporter:  nus                |       Owner:              
        Type:  bug                |      Status:  new         
    Priority:  high               |   Milestone:  7.8.1       
   Component:  Runtime System     |     Version:  7.4.2       
    Keywords:                     |          Os:  Windows     
Architecture:  x86                |     Failure:  None/Unknown
  Difficulty:  Unknown            |    Testcase:              
   Blockedby:  3658               |    Blocking:              
     Related:  #2283 #3242 #1883  |  
----------------------------------+-----------------------------------------

Comment(by awson):

 I'd want to clarify things a bit here.

 Suppose we have some compiled dll exporting some function `foo`. Suppose
 we write a client program in C calling this `foo`. Regardless of how this
 `foo` is prototyped: as bare `foo` or as {{{__declspec(dllimport) foo}}} a
 client program will happily call it, but depending on a prototype in
 ''different ways'': in the first case this will be {{{call foo}}} and if
 this symbol is external a linker will generate a thunk for this `foo` as
 {{{jmp __imp_foo}}}, in the second case a C compiler always generates
 {{{call __imp_foo}}}.

 Thus the single thing matters here: '''which prototype of a function'''
 was visible to C compiler when it compiled a code calling that function.
 If that prototype had {{{__declspec(dllimport)}}} attribute attached, a C
 compiler generated a call against {{{__imp_foo}}}, otherwise - a call
 against bare {{{foo}}}. GHC FFI of modern era (with no C backend) always
 generates the second variant AFAIK.

 This also explains the difference between 32 and 64 GHCs for Windows.
 64-bit GHC is distributed with mingw-w64 headers which use
 {{{__declspec(dllimport)}}} extensively, and many packages fail to
 compile. 32-bit GHC is distributed with mingw headers which has almost (or
 entirely?) no {{{__declspec(dllimport)}}} declared APIs.

 To make 64-bit GHC usable on Windows I manually removed all
 {{{__declspec(dllimport)}}} from mingw-w64 headers and now it all works
 smoothly.

 Hope this helps.

-- 
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/7097#comment:19>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler