This implements the TODO that I left as a comment from #15722.
In order to simplify the handling of deleting an absolute rpath that has
a relative duplicate (or vice-versa, i.e., a relative rpath with an
absolute duplicate), we relocate all rpaths first in one pass and then
delete the duplicates in a separate pass.
We currently rely on some lower-level (but still public) methods from
ruby-macho since the standard `#delete_rpath` method changes the order
in which rpaths are resolved. We can switch back to using
`#delete_rpath` when Homebrew/ruby-macho#555 is merged and released.
This should fix the failures seen for `julia` in Homebrew/core.[^1]
I've detailed a better/more comprehensive fix as a `TODO` in a comments.
However, the problems that the better fix would avoid are comparatively
unlikely, so I think we can try this one out for now while I work on
implementing the said fix.
[^1]: https://github.com/Homebrew/homebrew-core/pull/135398#issuecomment-1643041541
Doing `change_rpath(old, new, file)` will error if `new` is already an
rpath for `file`. When this happens, `old` is no longer needed, so we
can delete it.
Fixes a build failure at shivammathur/homebrew-php#1848.
Some formulae (e.g. `php`) use rpaths that reference Cellar paths
belonging to other formulae. Let's make sure these rpaths don't break by
making them use opt paths instead.
Stuff built by CMake evades this check because CMake normalises
`/private/tmp` (which is the default `HOMEBREW_TEMP`) to `/tmp`. See
https://gitlab.kitware.com/cmake/cmake/-/issues/23251.
Let's fix that my taking this into account when `HOMEBREW_TEMP` is
`/private/tmp`.
This wasn't working with casks because the bottle tag
would be nil here.
It was refactored to not use the bottle tag because
casks don't have bottles.
I also moved the valid_casks? method to extend/os/mac
because casks only run on macOS and the generic OS
tests were failing before.
- check the version of `/usr/bin/ld` for support of `-no_fixup_chains`
- check for usage of the `-fuse-ld` flag, since this flag is only
supported by Apple ld64
Also, call `no_fixup_chains` when setting up the build environment.
Invoking `ld` with `-undefined dynamic_lookup` emits a warning starting
Xcode 14:
ld: warning: -undefined dynamic_lookup may not work with chained fixups
Chained fixups is a linker optimisation that results in faster binary
load times, and is enabled by default starting Xcode 13 when the target
is macOS 12 or newer.
However, this interacts poorly with `-undefined dynamic_lookup`, and
Xcode will disable chained fixups when it is invoked with this flag
starting Xcode 14.3. Until then, we may be shipping binaries that are
broken in subtle ways, so let's disable chained fixups when necessary
instead.
I patterned the changes here after the handling of `-no_weak_imports`.
The only difference is that we need to check the flags that were passed
to the linker first to see if we do need to disable chained fixups.
For additional context, see:
https://developer.apple.com/documentation/xcode-release-notes/xcode-13-release-noteshttps://www.wwdcnotes.com/notes/wwdc22/110362/https://www.emergetools.com/blog/posts/iOS15LaunchTimehttps://github.com/python/cpython/issues/97524https://github.com/pybind/pybind11/pull/4301
