`cc <file> -o /dev/null` fails on aarch64-darwin

[abathur]

I noticed OfBorg failing to build oil-dev on aarch64-darwin.

It's failing on a ~sanity-check Oil's configure script is performing. I think I've successfully boiled the failing check down to a nix-shell oneliner that works on x86_64-darwin but fails on aarch64-darwin as below:

$ nix-shell -p stdenv --command 'cc -o /dev/null -x c <(echo "int main(void){ return 0; }"); echo $?'
libc++abi: terminating with uncaught exception of type SigTool::NotAMachOFileException: std::exception
/nix/store/r2pg5y3iyvsdx996iqynm4b414blbwpc-post-link-sign-hook: line 2: 95193 Abort trap: 6           CODESIGN_ALLOCATE=codesign_allocate /nix/store/pil07xvm57xbiczfqqj0cmrycwimapr5-sigtool-0.1.2/bin/codesign -f -s - "$linkerOutput"
clang-11: error: linker command failed with exit code 134 (use -v to see invocation)
134

I'm not really familiar with anything at this level, but dropping -o /dev/null causes the invocation to work, and it seems plausible that the post-link-sign-hook trying to codesign /dev/null could cause trouble.

I don't know what the appropriate fix is, but I see where /dev/null would get picked up and set to $linkerOutput: https://github.com/NixOS/nixpkgs/blob/538a698388eb5ab1209c658e9223fa81ae255a6f/pkgs/build-support/bintools-wrapper/ld-wrapper.sh#L165-L181

@thefloweringash

[abathur]

I've talked to @thefloweringash in matrix a bit (starting here), but we haven't quite unpicked this. I'm going to go ahead and work around it for my case, so I'll try to document what we've got so far.

1. The less-hacky way to fix this is probably updating cctools-port, since it looks like they've made progress on signing (especially the now-merged https://github.com/tpoechtrager/cctools-port/pull/114)
2. But, it seems like the SDK version is biting us again a bit on making this jump. I start seeing missing symbol failures for open_memstream (on x86_64-darwin, at least) from https://github.com/tpoechtrager/cctools-port/commit/86cf74fd50016550703435302c33c17474759666

3. It looks like they attempted to address this problem in https://github.com/tpoechtrager/cctools-port/pull/111, but my attempt to build still fails after this. I don't have a good grasp of the feature-checking API here and how it interacts with my system version and the SDK version nixpkgs is using, but here's what Andrew thought:

   IIUC, the availability stuff works like this: symbols are tagged with availability ranges, symbols that might not be available according to the compile-time -mmacos-version-min are weakly linked, applications must check at runtime (old way: symbol value is null, new: way via __builtin_available). So after 111, it can run on macos 10.12 if built with an sdk that is 10.13 or newer. to build with 10.12, we can probably #define HAVE_OPENMEMSTREAM_RUNTIME 0. it gets a little further but fails on DISPATCH_APPLY_AUTO which is also new in 10.13.

4. Andrew has some WIP towards this end already, visible in https://github.com/NixOS/nixpkgs/compare/master...thefloweringash:cctools-update

[tanshihaj]

Maybe for now we can just wrap this hook https://github.com/NixOS/nixpkgs/blob/master/pkgs/top-level/darwin-packages.nix#L123-L124 with if [ "$linkerOutput" != "/dev/null" ]; then ...; fi ?

[stephank]

I found this issue while trying a cctools upgrade myself. The PR for that is here: https://github.com/NixOS/nixpkgs/pull/185656

1. The less-hacky way to fix this is probably updating cctools-port, since it looks like they've made progress on signing (especially the now-merged https://github.com/tpoechtrager/cctools-port/pull/114)

Unfortunately, this change causes segfaults when using strip on non-binaries, which Nix does a lot. So the upgrade I did is up to the commit right before it. I didn't attempt a fix, only left a comment there.

4. Andrew has some WIP towards this end already, visible in https://github.com/NixOS/nixpkgs/compare/master...thefloweringash:cctools-update

I read over this before starting. Would've saved some time. 🤦‍♂️ Good thing we ended up doing much of the same.