New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

enable-split-objs #1284

Closed
tinkyholloway opened this Issue Nov 4, 2015 · 4 comments

Comments

Projects
None yet
3 participants
@tinkyholloway

tinkyholloway commented Nov 4, 2015

Feature request

(Apparently) there is a cabal configure option --enable-split-objs that passes --split-objs to ghc for project sources and dependencies. This creates one object file per function and therefore can reduce the size of resulting binaries as the linker only includes necessary objects files (functions).

The cabal configure --enable-split-objs is cited as a solution to the "large binary" problem (http://stackoverflow.com/questions/9198112/haskell-unnecessary-binary-growth-with-module-imports/9198223#9198223, http://stackoverflow.com/questions/6115459/small-haskell-program-compiled-with-ghc-into-huge-binary/6115703#6115703, http://stackoverflow.com/questions/12019072/compilation-dependencies-and-executable-size-with-ghc-in-linux/12019307#12019307) and there are deployments where a reduced size, statically linked binary is preferred.

@mgsloan mgsloan added this to the P3: Optional milestone Nov 5, 2015

@borsboom

This comment has been minimized.

Contributor

borsboom commented Nov 11, 2015

I agree, this would be a good enhancement. A pull request would be welcome.

@mgsloan

This comment has been minimized.

Collaborator

mgsloan commented Mar 3, 2016

Should split-objs be on by default? AFAIK the tradeoff is between compilation time and output size. I wonder how large the impact to compiletime is.

@mgsloan

This comment has been minimized.

Collaborator

mgsloan commented Mar 15, 2016

Initial support done, with the following caveats:

Building with --split-objs is enabled. Note that this feature is EXPERIMENTAL, and its behavior may be changed and improved. You will need to clean your workdirs befure use. If you want to compile all dependencies with split-objs, you will need to delete the snapshot (and all snapshots that could reference that snapshot.

This will hopefully be improved by the resolution of the cluster of issues around #1265 .

I actually got a segmentation fault out of stack built with --split-objs (but not its deps), so I'm not sure if this stuff is fully reliable (another reason for the EXPERIMENTAL marking). Doing another --split-objs build did not reproduce the issue.

@mgsloan

This comment has been minimized.

Collaborator

mgsloan commented Mar 15, 2016

Till #1265 is addressed, if you want to use split-objs all the time and don't want to worry about clearing out snapshots so that they can be rebuilt, then a good approach is to add the following to your config.yaml:

build:
  split-objs: true

@mgsloan mgsloan closed this Mar 15, 2016

mgsloan added a commit that referenced this issue Mar 15, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment