#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: | ---------------------------------+---------------------------------------- Comment (by rassilon): Replying to [comment:46 bgamari]:

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),

Your understanding doesn't match my understanding of the PE/COFF specification. Page 75 of the 02/06/2013 version of the spec which is the page where the Export Ordinal Table of the `.edata` section is described. The section includes pseudo-code explaining how the SymbolRVA of a named symbol is determined: i = Search_ExportNameTable(ExportName); ordinal = ExportOrdinalTable[i]; SymbolRVA = ExportAddressTable[ordinal - ordinalBase]; So, the problem isn't with this pseudo-code, but the pseudo-code combined with the Export Ordinal Table being defined as:

...

`The export ordinal table is an array of 16-bit indexes into the address table.`

...

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

This is especially sad, since the Address Table Entries field of the Export Directory Table is 32 bits of data. The text you quote below is from the syntax of .DEF files explaining why 16-bit DLLs, didn't include exported symbol string names and utilized the ordinal number as the ONLY `API` between DLLs. The documentation you quote is recommending usage of string symbols for providing a cross-DLL `API` resolution and only using the ordinal `API` for legacy reasons. The documentation doesn't mean to imply that ordinals are optional (based on my reading of the PE/COFF sections about .edata). the ordinal and the function, you can use the function name as you normally would in projects that use the DLL.

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