[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:                |
---------------------------------+----------------------------------------

Comment (by rassilon):

 Replying to [comment:49 thomie]:
 > rassilon: you seem to know stuff. How to fix dynamic linking on Windows?
 Some more problems here: #4824 #5620 #7665 #8228.

 The "easiest" way of fixing this issue is by refactoring the GHC internals
 in such a way as to minimize the dependencies between the partitions of
 the GHC base DLL. (in short, removing all need for Haskell source level
 cyclic imports could help a bunch here)

 Either that, or come up with an automatic partitioning scheme that could
 handle cyclic references between the partition DLLs.

 The PE/COFF limitation of only being able to export 16bits worth of APIs
 from a dynamic library is the biggest problem of all of these issues.
 #5620 would only be worth addressing when we have a solution to this issue
 one way or another.

 Given that the root of the 16bit exported API problem stems from the
 PE/COFF specification, it would seem that any alternatives we come up
 would be conceptually equivalent to our current usages of non-dlopen(or
 equivalent) dynamic loading/linking that RTS/GHCi do today. In fact the
 code necessary to fix this issue would probably make that logic even more
 convoluted and difficult to understand/maintain. (Since the code would
 need to understand whatever additional sections/per-DLL API
 functions/etc.. that would allow the code to be relocated and linked
 properly.)

 Such a scheme would have additional downsides as well:
 * It would be (by necessity) be Windows specific.
 * It would probably completely shatter the mechanism for calling Haskell
 functions from C/C++ either in the same DLL or another DLL.

 Of the possible above approaches, I would think an automatic partitioning
 approach that handled cyclic references between the partitions would be
 the approach that had the best long term chances of successfully being
 maintained.

 Having said that of course, even automatic partitioning is still a non
 trivial amount of work. Since ideally, Cabal would know about DLL
 partitioning as well so that when anyone referenced a Haskell package with
 partitions, Cabal would help (or direct) GHC to link against all of the
 partition DLLs of that package.

 Ugh. Maybe it'll be easier once Microsoft lets us push a pull request to
 Window's dynamic linker to support more than 16bits of ordinals for
 Windows 20. ;)

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