Skip to content
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.

Sign up for GitHub

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

Jump to bottom

[ghc] fix dylib load command limits #40877

Closed
wants to merge 3 commits into from
Closed

[ghc] fix dylib load command limits #40877

wants to merge 3 commits into from

Conversation

angerman
Copy link
Contributor

Motivation for this change

See https://phabricator.haskell.org/D4714 for the full details.
This will be part of ghc 8.6.

Things done
  • Tested using sandboxing (nix.useSandbox on NixOS, or option build-use-sandbox in nix.conf on non-NixOS)
  • Built on platform(s)
    • NixOS
    • macOS
    • other Linux distributions
  • Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
  • Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
  • Tested execution of all binary files (usually in ./result/bin/)
  • Fits CONTRIBUTING.md.

@angerman angerman requested a review from peti as a code owner May 21, 2018 11:28
@angerman
Copy link
Contributor Author

cc @Ericson2314 @matthewbauer

We can probably just drop the linker hack with this, and reenable #37750 (e.g. revert 970f2b5) as well.

I'm positive the patch is good for 8.0, and I think for 8.2 as well, for 8.4 we might need to drop the OSiOS. Also 8.4 has logic for -dead_strip, so we could potentially drop that line as well.

In general there is an issue though with using -dead_strip when using the LLVM backend. Should
we conditionalize it on the LLVM backend, or just drop OSiOS and -dead_strip outright?

@angerman
Copy link
Contributor Author

Alright, after reconsidering what I just wrote, I did drop OSiOS and -drop_dead. The reasoning is the following, for iOS, you are very unlikely to use GHC prior to 8.4 with any substantial success anyway. Also the whole dynamic issue doesn't come up with stage1 compilers usually as they are built using the internal static linker and I don't think they even built dynamic libs by default.

Also -dead_strip can be bolted on as we used to do prior to the linker hack, so we might not need to force it in GHC.

@peti
Copy link
Member

peti commented May 21, 2018

Merged to haskell-updates for testing in 0524d6b4020f2c19b83bbaa63bd1c88599f6d861. I'll merge to master ASAP.

peti
peti approved these changes May 21, 2018
View reviewed changes
Copy link
Member

@peti peti left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just waiting for test builds ...

@Ericson2314
Copy link
Member

Good stuff! Can we fetchpatch this?

@angerman
Copy link
Contributor Author

@Ericson2314 I guess we could try to fetchpatch it, not sure if necessary though?

@peti peti closed this in 4b2ecea May 22, 2018
@peti
Copy link
Member

peti commented May 22, 2018

@angerman, if we can fetchpatch the file, then yes, please do that rather than checking the file into Nixpkgs.

domenkozar pushed a commit that referenced this pull request Jul 4, 2018
@angerman @domenkozar
ghc: fix dylib load command limits in compiler version 8.x
56fad14 
See https://phabricator.haskell.org/D4714 for the full details.
This will be part of ghc 8.6.

Closes #40877.

(cherry picked from commit 4b2ecea)
Signed-off-by: Domen Kožar <domen@dev.si>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@peti peti peti approved these changes

Assignees
No one assigned
Labels
6.topic: haskell 10.rebuild-darwin: 501+ 10.rebuild-linux: 0
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

None yet
4 participants
@angerman @peti @Ericson2314 @GrahamcOfBorg