Opened 11 years ago

Closed 8 years ago

Last modified 8 years ago

#3345 closed feature request (fixed)

Support reading .a files in GHCi to reclaim some disk space

Reported by: batterseapower Owned by:
Priority: high Milestone: 7.4.1
Component: Compiler Version: 6.10.2
Keywords: Cc: pho@…
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:

Description

Currently, Cabal builds two code files for every libary it installs:

mbolingbroke@mb566 ~/.cabal/lib/vector-space-0.5.6/ghc-6.10.1
$ ls
.
..
Data
HSvector-space-0.5.6.o
libHSvector-space-0.5.6.a

The .a is a straight concatenation of the .o files that got built. The .o is the result of lding together all the .o files (and so has inter-object references already resolved) but is actually only used by GHCi.

If GHCi could support loading .a files then Cabal wouldn't have to build this extra .o file and we could cut the size of installed libraries almost in half.

(Or perhaps GHC could link against the .o rather than the .a, and then Cabal could stop building the .a, instead?)

[12:32] BSP_: does cabal build both .o and .a's for a library purely because ghci isn't capable of reading the .a format and loading each .o individually?
[12:33] BSP_: it seems a bit wasteful to have two copies of the code installed for each library...
[12:35] dcoutts: BSP_: that's correct
[12:35] dcoutts: in theory it's not that hard
[12:35] dcoutts: there's no real need for ghci to read the .a index, just link in everything
[12:36] arjanb left the chat room. ("bbl")
[12:36] dcoutts: the .a format is trivial
[12:36] • dcoutts has a parser
[12:36] dcoutts: and generator for that matter

Change History (8)

comment:1 Changed 11 years ago by igloo

difficulty: Unknown
Milestone: 6.14.1

The alternative will be for GHCi to use dynamic libraries.

comment:2 Changed 10 years ago by igloo

Type of failure: None/Unknown

See also #4153

comment:3 Changed 9 years ago by igloo

Milestone: 7.0.17.2.1
Priority: normalhigh

The core of this is now done, and we use the .a files on OS X. There is still some polishing to do (e.g. it currently always uses mmap to allocate memory for the object files, and maps memory separately for each individual object file), so we won't do it in time for 7.0, but it's entirely feasible for 7.2.

comment:4 Changed 9 years ago by simonmar

I suggest we make the GHCi .o files optional, on all platforms, and make the linker fall back to using the .a file if it can't find the .o file. Then we simply disable the .o file for the GHC package unconditionally, thus saving a lot of space in the binary distributions in exchange for a slower loading of the GHC package - a fair tradeoff I think.

comment:5 Changed 9 years ago by PHO

Cc: pho@… added

comment:6 Changed 9 years ago by igloo

It shouldn't even be much slower for the GHC package, as we already have object splitting turned off for it.

comment:7 Changed 8 years ago by simonmar

Resolution: fixed
Status: newclosed

I believe this is done. We don't build or ship the GHCi library for the GHC package, and GHC falls back to using the .a file whenever it can't find a .o file for a package. It should be safe to always use --disable-library-for-ghci with Cabal (but perhaps a little slower to load the package into GHCi).

comment:8 Changed 8 years ago by marlowsd@…

commit efcbe14df849dc1acc810253f4e0c725bb2d7a12

Author: Simon Marlow <marlowsd@gmail.com>
Date:   Tue Nov 8 10:28:56 2011 +0000

    update docs regarding .a files and GHCi (#3345)

 docs/users_guide/packages.xml |   56 ++++++++++++++++++----------------------
 1 files changed, 25 insertions(+), 31 deletions(-)
Note: See TracTickets for help on using tickets.