#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