fix: not use ld.gold on aarch32 #548
Merged
+9
−12
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
It seems that using ld.gold for cross-compilation to aarch32 results in Haskell programs segfaulting when launched.
|
bors try |
tryBuild succeeded |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
It seems that ld.gold is responsible for cross-compiled programs (from x86_64 to armv6l with Linux at the very least) to segfault before having a chance to actually start when using the
perf-crossflavour. That includes the instance ofremote-iservused during cross-compilation.Returning to ld seems to fix that issue, and compiled programs run just fine with
perf-cross. However, I can't find the reference to the reason why in some cases ld.gold is actually required anymore. So maybe this PR is not suited for every cases? However it runs fine on a cross-compilation scenario to armv6l with ffi interactions. So at the very least, if the PR can help...A reference to an issue that may be linked, though I'm not quite sure (I'm not using musl, and my segfault event doesn't look like the one referenced in the issue):
NixOS/nixpkgs#49071
On another note, without this PR, I've managed to get some cross-compiled programs to partially work (they do start, but segfault on some other parts) by modifying the compilation flags. But after experimenting, I've stumbled upon some issues in the GHC issue tracker that kind of look like what was happening, so perhaps this issue is already investigated?
Have a nice day!