Keg relocation should also relocate `RPATH`s on macOS

[carlocab]

Provide a detailed description of the proposed feature

On macOS, the relocation of kegs does not touch LC_RPATH entries in MachO files. This behaviour differs from that on Linux, where RPATHs are relocated, and I believe this partly explains why more formulae are relocatable on Linux than on macOS.

I propose that brew also apply the existing relocation logic to LC_RPATH entries. That is, it should substitute path prefixes in each LC_RPATH entry with the appropriate placeholders (e.g. @@HOMEBREW_PREFIX@@, @@HOMEBREW_CELLAR@@, etc) upon bottling, and substitute those placeholders with the correct prefixes upon pouring.

This complements #10846. Personally, I think this should be implemented first before we do any binary patching.

There is some existing (but, AFAICT, unused) logic in brew that clears MachO files of "unused" RPATHs:

brew/Library/Homebrew/extend/os/mac/keg_relocate.rb

Lines 57 to 65 in 42ffee7

	# If none of the install names reference RPATH(s), then we can safely
	# remove all RPATHs from the file.
	if ENV["HOMEBREW_RELOCATE_METAVARS"] &&
	file.dynamically_linked_libraries.none? { |lib| lib.start_with?("@rpath") }
	# NOTE: This could probably be made more efficient by reverse-sorting
	# the RPATHs by offset and calling MachOFile#delete_command
	# with repopulate: false.
	file.rpaths.each { |r| file.delete_rpath(r) }
	end

but my (admittedly limited) testing suggests that the test it uses for deciding whether to clear redundant RPATHs is incorrect, and actually breaks formulae.

What is the motivation for the feature?

More relocatable bottles.

How will the feature be relevant to at least 90% of Homebrew users?

Probably won't be.

What alternatives to the feature have been considered?

Doing nothing, or just relying fully on binary patching instead.

[carlocab]

To be clear, I am willing to work on this (but not immediately). However, I am opening this issue in case this is actually not a good idea for reasons I haven't considered.

CC @sjackman @danielnachun

[MikeMcQuaid]

This seems like a good idea given my limited understanding.

[Bo98]

This would help with Swift. The current approach I'm doing is deleting the absolute rpath (becuase in the Swift case, it's actually a duplicate of an already existing relative path and thus pointless).

There's an argument that the absolute rpath should be fixed at source, but this sometimes isn't possible and can require patches.

[Bo98]

As for HOMEBREW_RELOCATE_METAVARS, I agree that should be deleted. It does look like it would cause problems.

[sjackman]

Makes sense to me. Thanks, Carlo!

[danielnachun]

Personally, I think this should be implemented first before we do any binary patching

I completely agree, and I actually proposed #10846 under the assumption that we were already doing this. Since we are not, I fully support getting this working before trying to do binary patching on macOS.

One question that may warrant some further thought: should we be checking if the user is actually running a non-default cellar before doing this? If they are not, then we end up replacing the old install prefix in the RPATHs with the same one. This is harmless but arguably unnecessary. I'm not actually sure we even check that for patching install_names on macOS or RPATHs on Linux.

When #10846 is implemented, install_name/RPATH patching will be mandatory for bottles built with long prefixes because all users will have a different install prefix than the one used to build the bottle. However, bottles which don't need binary patching could still be built with the default prefix and would only need install_name/RPATH patching when the user is in a non-default cellar.

[Bo98]

should we be checking if the user is actually running a non-default cellar before doing this?

The bottles contain @@HOMEBREW_PREFIX@@ - we don't actually scan for /usr/local at pour time. A similar practice would be done here where the RPATHs will be replaced with @@HOMEBREW_PREFIX@@.

[carlocab]

This would help with Swift.

I've been contemplating RPATH relocation on and off for a little while now, but your comment about making Swift relocatable did encourage me to open this issue. And this: #11331

[carlocab]

I've merged #11331. RPATH relocation is currently gated behind HOMEBREW_RELOCATE_RPATHS, which I intend to test more thoroughly at https://github.com/carlocab/homebrew-rpath-test.