fix potentially broken install_name_tool

[angerman]

We by default try to pull the one from the targetCC, only if that fails fall back to the bintools one.

[thomasjm]

Hi @angerman , any chance I could ask you a follow-up question about this?

I have a problem that seems very similar to the original issue, but it happens when trying to link my final executable. Everything up until the final linking works great, thanks to this patch. But then I see an error like this:

       > /nix/store/3npblfzpc62lnby7l43hh1ql2k4ybd8j-clang-wrapper-16.0.6/bin/ld: line 269: 58495 Segmentation fault: 11  /nix/store/r4z0c8m95f6gp0zyrcxg0mr6m9fmsnn0-cctools-binutils-darwin-16.0.6-973.0.1/bin/ld @<(printf "%q\n" ${extraBefore+"${extraBefore[@]}"} ${params+"${params[@]}"} ${extraAfter+"${extraAfter[@]}"})
       > clang-16: error: linker command failed with exit code 139 (use -v to see invocation)
       > ghc-9.8.2: `cc' failed in phase `Linker'. (Exit code: 1)

As you can see, it mentions /nix/store/...-clang-wrapper-16.0.6/bin/ld, but it also mentions /nix/store/.../cctools-binutils-darwin-16.0.6-973.0.1/bin/ld.

You had said on the other issue (https://gitlab.haskell.org/ghc/ghc/-/issues/25478) that the binutils one contains an install_name_tool that corrupts dylibs. Is it possible that the ld it includes will also cause problems?

Any help would be greatly appreciated, I'm at a loss for how to debug this or even to identify if a given dylib is corrupted or not.

[thomasjm]

Interestingly, I got it to build successfully by passing these configureFlags, to set it to just use the system ld:

--ghc-options="-optl=-fuse-ld=/usr/bin/ld"

and doing this reproduces the same error:

--ghc-options="-optl=-fuse-ld=${pkgs.clang_16}/bin/ld"