Ticket #3347 (closed feature request: fixed)

Opened 3 years ago

Last modified 3 years ago

Add flag to prevent generation of import libraries on Windows

Reported by: batterseapower Owned by: igloo
Priority: normal Milestone: 6.12.1
Component: Compiler Version: 6.10.2
Keywords: Cc: ndmitchell@…, batterseapower@…
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: Difficulty: Unknown
Test Case: Blocked By:
Blocking: Related Tickets:

Description

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.

Attachments

NoSharedImplib.patch Download (4.9 KB) - added by batterseapower 3 years ago.
Implementation of -fno-shared-implib

Change History

Changed 3 years ago by batterseapower

Implementation of -fno-shared-implib

Changed 3 years ago by NeilMitchell

Max mentions .lib's of ~2.5Mb, but .lib's can be as big as 60Mb.

An alternative to this patch would be to disable the creation of .lib's by default, and add a flag -shared-implib to enable it. The email thread suggests that GNU can link against the .dll's directly, and MSVC can't link against the .lib's at all - if so then they are a bit useless.

Is there a flag to indicate bugs which contain patches? I think projects like Mozilla do, and it helps them review and apply patches before they go stale.

Changed 3 years ago by igloo

  • owner set to igloo
  • difficulty set to Unknown
  • milestone set to 6.12.1

Thanks for the report and patch; I'll take a look.

Changed 3 years ago by igloo

  • status changed from new to closed
  • resolution set to fixed

Patch applied (rerecorded to avoid conflict); thanks!

Note: See TracTickets for help on using tickets.