GitLab

The import libraries generated when you use the -shared option to generate a library can be very big. For example, when using it to build the edit-distance library from Hackage (v0.1.2) I observed a DLL size of 2.7Mb and an import library size of 2.2Mb. (See also http://www.nabble.com/--out-implib-when-linking-shared-libraries-tt23561017.html)

Due to these size concerns, it may be desirable to disable the generation of the import library altogether in cases where the user only wants to use dynamic linking. The attached patch adds a new flag, -fno-shared-implib, that does just that.

NB: after experimentation I have found that there are at least two ways to reduce the size of the generated import library:

• Use pexports from mingw-utils to generate a .def file from the generated .dll, and then use lib /def:<deffile> to generate an import library from that. (NB: may be an issue with underscores added/removed in exported names - I haven't checked this). This generated a 825kb import library in my experiment above.
• Unpack the .dll.a generated by the binutils ld and link the contents together. This should be equally functional as an import library, but it reduces the disk space requirements to a similar level as the other option (815kb in my test).

The basic root of the problem is that the import libraries generated by GNU dlltool / ld are pretty bloated compared to those from the Microsoft toolchain. However, even the MS toolchain can't do much better than 30% of the size of the code, because Haskell code just exports tons of symbols (~3200 in my test, which of course includes not only the library but the RTS, base library etc). This should be ameliorated by the implementation of shared libraries on Windows.

Trac metadata

Trac field	Value
Version	6.10.2
Type	FeatureRequest
TypeOfFailure	OtherFailure
Priority	normal
Resolution	Unresolved
Component	Compiler
Test case
Differential revisions
BlockedBy
Related
Blocking
CC	batterseapower@hotmail.com, ndmitchell@gmail.com
Operating system
Architecture