Linking hack for macOS Sierra#27536
Conversation
|
@Ericson2314, thanks for your PR! By analyzing the history of the files in this pull request, we identified @pikajude, @edolstra, @vcunat, @LnL7 and @copumpkin to be potential reviewers. |
|
I'm getting |
|
We don't have LTO support, not sure why you're running into that tho. See #19312 |
|
@Ericson2314 The patch is not much shorter than the wrapper itself, any chance we can either factor out the common bits better or just have a second wrapper? 😕 |
|
Another approach would be patching Cabal (although I'm not sure how much would break): commercialhaskell/stack#3209 (comment) EDIT: not to discourage this work (thank you John!), I'm still thinking about possible alternatives since it's mostly Haskell that's affected. |
|
@shlevy Ah, second inner wrapper with mutual recursion makes a lot of sense—didn't think of that I'll switch. |
|
@Ericson2314 so @copumpkin proposed to patch GHC linker and upstream the change, which I think makes more sense. This would fix the issue for non-Nix users which is clearly a more general solution (for Haskell, but not for non-Haskell in Nix). |
|
If this is working I'd rather not have to wait for the GHC linker change... We can always turn this off once we're sure the GHC fix is sufficient |
|
Another potential solution is to use haskell/cabal#3979 |
|
@domenkozar is that different from #25537 ? |
|
@shlevy it's not, but then I don't understand how you're still seeing the problem with nixpkgs? :) |
|
@domenkozar Kept adding deps to our haskell packages and hit it again 😄 |
|
I think this is a good thing to have around Nixpkgs regardless. Our need is Haskell, but the problem is not Haskell-specific (that is, if other languages can get on our level of code reuse 😏). |
80f8d67 to
d1c0e3e
Compare
There was a problem hiding this comment.
Looks like reexport-delegate isn't referenced anywhere but from this script itself, how does this get called? 😕
There was a problem hiding this comment.
Yeah I had those messed up; fixed later.
f3e7d5d to
1286947
Compare
|
|
d590e3f to
8360abc
Compare
|
Now, I get linking failures without a message. Pushing a commit with debug stuff in case anyone else wants to look. |
4713d0a to
40825d8
Compare
|
By the way, yesterday got back to |
f0c4e68 to
5a15ea8
Compare
|
CC @orivej --- you've done some great ld-wrapper work, including improving further on style things I pointed out with the old code, so pinging you lest I forget anything here. |
Probably best to override Haskell packages set, or anything else linking a lot of libraries, with this.
As described in NixOS#18461, MacOS no longer accepts dylibs which only reexport other dylibs, because their symbol tables are empty. To get around this, we define an object file with a single "private extern" symbol, which hopefully won't clobber anything.
There was a problem hiding this comment.
@copumpkin @LnL7 / other Darwin people. I just cargo-culted -macosx_version_min 10.10 from elsewhere, and it's probably necessary. What should it be, if it is passed anything at all?
There was a problem hiding this comment.
you can use $MACOSX_DEPLOYMENT_TARGET, that's defined in the stdenv.
9967a96 to
134b713
Compare
Also add appropriate `meta.platforms = ...` to each derivation.
134b713 to
14e05c3
Compare
|
Anyone have any opinions on how I've organized things (especially since this last commit)? |
| shell = "${pkgs.bash}/bin/bash"; | ||
|
|
||
| cc = import ../../build-support/cc-wrapper { | ||
| cc = lib.callPackageWith {} ../../build-support/cc-wrapper { |
There was a problem hiding this comment.
It adds the override field so I can replace cc while leaving everything else the same. Probably should add a note for that.
| case "${!n}" in | ||
| -l*) let overflowCount+=1 ;; | ||
| -reexport-l*) let overflowCount+=1 ;; | ||
| *) ;; |
There was a problem hiding this comment.
Should we handle -- here or elsewhere?
There was a problem hiding this comment.
Oh I wasn't aware of it; looking up.
There was a problem hiding this comment.
You mean just plain paths to dylibs passed in? I didn't see any -- in the man page.
There was a problem hiding this comment.
I just mean the standard -- to separate command line flags from files that start with --, no idea if ld supports it but most tools do.
There was a problem hiding this comment.
@shlevy Well I don't yet handle libraries passed in by path yet at all, in fact.
There was a problem hiding this comment.
@shlevy Well I don't yet handle libraries passed in by path yet at all, in fact. I'll look into -- and that.
There was a problem hiding this comment.
Eh, let's just do this as followup if needed.
| if bad-asdf | ||
| then echo "bad-asdf can succeed on non-sierra, OK" >&2 | ||
| else echo "bad-asdf should fail on sierra, OK" >&2 | ||
| fi |
There was a problem hiding this comment.
I don't love that we won't be able to catch regressions due to the exe just no longer breaking the limit for some reason
There was a problem hiding this comment.
Neither do I. But I couldn't think of anything better without much more work.
| ;; | ||
| -l) | ||
| echo "cctools LD does not support '-L foo' or '-l foo'" >&2 | ||
| exit 1 |
There was a problem hiding this comment.
How can a general purpose linker just fail to process these args? This is bound to break linking something.
There was a problem hiding this comment.
Well, I suppose the man page could be wrong. I thought i tested too but let me double check.
There was a problem hiding this comment.
Note that this isn't a failure to parse -Lpath or -llib, just -L path and -l lib. The latter is supported by the GNU toolchain nowadays but can't be expected to work everywhere (and, FWIW, from my understanding this is a limitation of the real linker program, not this script)
There was a problem hiding this comment.
I didn't know that macOS ld does not support these args without spaces, then there is no problem. This is funny, since it has quite a few arguments that start with -l (-lazy-l* -lazy_library -lazy_framework -lto_library).
There was a problem hiding this comment.
@orivej Yes I should special case the rest of those--I only did -lto_library.
14e05c3 to
85ce161
Compare
b8d2065 to
cd6c452
Compare
|
Somebody just ping me if this needs more features |
The workaround that this change deletes was initially contributed in NixOS#25537 to mitigate NixOS#22810 until a more permanent solution could be devised. That more permanent solution was eventually contributed in NixOS#27536, which now obviates the initial workaround, so this change removes it.
Motivation for this change
Sierra imposes and arbitrary limit on mach-o header sizes, preventing too many libraries form being linkned. Following @copumpkin's suggestion, we recursively divide the libraries between children using
-reexport-luntil the header size is presumed small enough."Fixes" #22810
Things done
(nix.useSandbox on NixOS,
or option
build-use-sandboxinnix.confon non-NixOS)
nix-shell -p nox --run "nox-review wip"./result/bin/)