[GHC] #13431: Linker error related to atan and ntdll on 32-bit Windows

[GHC]

#13431: Linker error related to atan and ntdll on 32-bit Windows
-------------------------------------+-------------------------------------
        Reporter:  RyanGlScott       |                Owner:  Phyx-
            Type:  bug               |               Status:  upstream
        Priority:  normal            |            Milestone:  8.4.1
       Component:  Compiler          |              Version:  8.0.1
      Resolution:                    |             Keywords:
Operating System:  Windows           |         Architecture:  x86
 Type of failure:  GHC rejects       |            Test Case:
  valid program                      |
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------
Changes (by Phyx-):

 * status:  new => upstream
 * milestone:   => 8.4.1


Comment:

 I believe this to be an upstream bug in `mingw-w64-crt`.

 It seems that `ntdll.dll` undocumented exports a few functions such as
 `atan`.

 The import libraries are created by default using a tool that scrapes the
 exports table of a dll and makes a `.def` file and then `dlltool` is
 called to generate the library.

 The problem is that this tool on the `x86` version seems to think these
 functions are `DATA` references (e.g. readonly data) instead of functions.
 And this it only exports `_imp__atan` instead of both `_atan` and
 `_imp__atan`.

 On `x64` the tool does get this correct.

 {{{
 Tamar at Kino MINGW64 ~/MINGW-packages/mingw-w64-crt-git/src/mingw-w64
 $ find -iname ntdll.def | xargs grep atan
 ./mingw-w64-crt/lib32/ntdll.def:atan DATA
 ./mingw-w64-crt/lib64/ntdll.def:atan
 ./mingw-w64-crt/libarm32/ntdll.def:atan
 }}}

 This will require some upstream patching because controlling the link
 order in all cases is very hard.

 In the meantime since it seems that `Win32` is the only one that's
 introducing this dependency, I think I can apply a patch locally there for
 `x86`.

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