id	summary	reporter	owner	description	type	status	priority	milestone	component	version	resolution	keywords	cc	os	architecture	failure	difficulty	testcase	blockedby	blocking	related
5292	libHSghc exports more symbols than Windows can handle	batterseapower		"If you build GHC with shared libraries enables, the generated libHSghc.dll will export 65536 symbols. This is the limit that Windows DLLs can handle (the source of the limitation is that they use 16-bit integers to represent ""ordinals"").

Unfortunately, this means that the generated DLL is actually missing a ton of exports! Bad things happen at this point, including runtime crashes in GHCs linker. One interesting feature is that there seems to be a bug with GetProcAddress for modules that have filled up their export lists like this, so if hmod is a handle to the loaded DLL, GetProcAddress(hmod, ""LocalAlloc"") will succeed even though LocalAlloc is not exported by the DLL.

The number of symbols exported varies wildly depending on how you build the compiler. A ""quick"" build (from build.mk.sample) only exports 39k symbols, which is under the limit, but the kind of build that validate does ends up hitting the limits. (This difference was the source of some fun debugging confusion for me...)

Because of this bug, we won't be able to distribute a dynamically linked GHC on Windows. It is also preventing me from getting plugins06 to pass on Windows.

One workaround would be to build GHC with settings that result in less exported symbols until we get below the limit again -- i.e. export less unfoldings. This might adversely impact compiler performance, however."	bug	new	low	7.6.2	Compiler	7.0.3				Windows	Unknown/Multiple	Runtime crash				5355