Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
  • Sign in / Register
GHC
GHC
  • Project overview
    • Project overview
    • Details
    • Activity
    • Releases
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 4,384
    • Issues 4,384
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
    • Iterations
  • Merge Requests 368
    • Merge Requests 368
  • Requirements
    • Requirements
    • List
  • CI / CD
    • CI / CD
    • Pipelines
    • Jobs
    • Schedules
    • Test Cases
  • Operations
    • Operations
    • Incidents
    • Environments
  • Analytics
    • Analytics
    • CI / CD
    • Code Review
    • Insights
    • Issue
    • Repository
    • Value Stream
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Members
    • Members
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • Glasgow Haskell Compiler
  • GHCGHC
  • Issues
  • #3345

Closed
Open
Opened Jul 03, 2009 by batterseapower@trac-batterseapower

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

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
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
Operating system
Architecture
Assignee
Assign to
7.2.1
Milestone
7.2.1
Assign milestone
Time tracking
None
Due date
None
Reference: ghc/ghc#3345