[GHC] #5987: Too many symbols in ghc package DLL

[GHC]

#5987: Too many symbols in ghc package DLL
---------------------------------+----------------------------------------
        Reporter:  igloo         |                Owner:
            Type:  bug           |               Status:  new
        Priority:  normal        |            Milestone:  8.0.1
       Component:  Compiler      |              Version:  7.5
      Resolution:                |             Keywords:
Operating System:  Windows       |         Architecture:  Unknown/Multiple
 Type of failure:  None/Unknown  |            Test Case:
      Blocked By:                |             Blocking:  5355
 Related Tickets:                |  Differential Rev(s):
       Wiki Page:                |
---------------------------------+----------------------------------------
Changes (by bgamari):

 * owner:  thoughtpolice =>
 * priority:  high => normal


Comment:

 Demoting priority as we have disabled dynamic linking on Windows (see
 comment:29).

 My understanding of this situation is that it is not an intrinsic
 limitation of PE. The relevant data structures are the `.edata` and
 `.idata` tables which are defined in sections 63 and 64 of the PE/COFF
 specification. The specification specifies that one means of referring to
 exported symbols is via a 16-bit ordinal. However, this is not the only
 way; if the lookup fails the loader will fall back to a standard name
 search. Indeed, Microsoft even explicitly says that ordinals
 [[https://msdn.microsoft.com/en-us/library/hyx1zcd3.aspx|are a legacy
 artifact]] and their use is discouraged in new code (this document
 describes the `.def` format, but the idea still applies),

 > You can use @ordinal to specify that a number, and not the function
 name, will go into the DLL's export table. Many Windows DLLs export
 ordinals to support legacy code. It was common to use ordinals in 16-bit
 Windows code, because it can help minimize the size of a DLL. We don’t
 recommend exporting functions by ordinal unless your DLL’s clients need it
 for legacy support. Because the .LIB file will contain the mapping between
 the ordinal and the function, you can use the function name as you
 normally would in projects that use the DLL.

 For this reason I believe the problem is in fact that `ld.bfd` is
 producing DLLs with symbols exported by (or perhaps objects that are
 imported by) ordinal.

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