-
Notifications
You must be signed in to change notification settings - Fork 841
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
Comments
I agree, this would be a good enhancement. A pull request would be welcome. |
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. |
Initial support done, with the following caveats:
This will hopefully be improved by the resolution of the cluster of issues around #1265 . I actually got a segmentation fault out of |
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 build:
split-objs: true |
Feature request
(Apparently) there is a
cabal configure
option--enable-split-objs
that passes--split-objs
toghc
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.The text was updated successfully, but these errors were encountered: