Add flag to prevent generation of import libraries on Windows
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.