[macOS] better rpath logic

[angerman]

This is the continuation of #7076

---

Please include the following checklist in your PR:

• Patches conform to the coding conventions.
• Any changes that could be relevant to users have been recorded in the changelog (add file to changelog.d directory).
• The documentation has been updated, if necessary.

Please also shortly describe how you tested your change. Bonus points for added tests!

[chessai]

Restarted the failed windows jobs

[chessai]

@phadej @bgamari could one of you review? This actually fixes a pretty annoying bug on MacOS. I can confirm that it works as intended (tested on 15+ dev machines).

[phadej]

I'm uneasy on this. I'd like to see the tests, which would break if that code is changed again.

So if we need to wait until GHC 9.2 or 9.0 is released with install_name_tool command in the --info to write a test, then we will wait. (The patch won't work anyway if you aren't using it with such GHC).

[emilypi]

Hi @angerman - let's talk about how to write tests for this, and I'd be happy to help see this through.

[ulysses4ever]

This is marked as "In progress" for 3.10. Is it?

[Kleidukos]

@angerman Yo! Do you need any help with this PR?

[andreabedini]

@angerman should we pick this up again? AFAIK ghc --info includes install_name_tool command since 8.10.7.

[alt-romes]

Note: if we decide to do this, we must carefully take into account that GHC will only keep as RPATHs the paths where linked libraries are found at link time. Specifically, some runtime paths should be included in the binary regardless of any library being found there at link time, if the user specifies so (namely extra-lib-dirs #7339).

So it is kind of fine if getRPaths were to return an empty list for GHCs which workaround the darwin linker issue by post-link-injecting the paths of the libraries found at link time to the RPATH entries, but I'm also not sure to what extent it is necessary, since the list is often not that long.

In fact, getRPaths is typically 2 or 3 directories only: the .cabal/ghc store where all external dependency libraries are stored. In my case, building a shared library these rpaths are computed:

-optl-Wl,-rpath,/Users/romes/.ghcup/ghc/9.8.1/lib/ghc-9.8.1/lib/aarch64-osx-ghc-9.8.1
-optl-Wl,-rpath,/Users/romes/.cabal/store/ghc-9.8.1/lib
-optl-Wl,-rpath,/Library/Developer/CommandLineTools/SDKs/MacOSX14.2.sdk/usr/lib

However, with nix stores I think one might get one path per dependency.

The paths determined by getRPaths/depLibraryPaths are likely where libraries are found at both linktime and runtime, so it should be fine to not pass them on on macOS, I guess.

[ffaf1]

Hello, I am going through old PRs to check whether they are stale.

If this PR is still “live”, write a comment and I will remove the consider closing label. Otherwise in ≃ 2 weeks this PR will be closed.