`dyld` uses the target library's install name to work out whether this
is a Framework or a dylib, which affects how `dyld` searches for the
desired library.
We should therefore avoid confusing `dyld` by including the
`*.framework` part of the install name in the target dylib, which is
what this change does.
Here's a concrete example of what this changes. Before:
❯ otool -L /usr/local/bin/python3
/usr/local/bin/python3:
@loader_path/../Python (compatibility version 3.11.0, current version 3.11.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1319.100.3)
After:
❯ otool -L /usr/local/bin/python3
/usr/local/bin/python3:
@loader_path/../../../../Python.framework/Versions/3.11/Python (compatibility version 3.11.0, current version 3.11.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1319.100.3)
By retaining the `Python.framework` part of the install name, we make
sure that `dyld` knows that it should be looking for a framework rather
than a dylib.
I noticed from
https://github.com/Homebrew/homebrew-core/actions/runs/5751070010 that
we're no longer creating reproducible bottles between macOS and Linux.
All macOS checksums have changed but Linux ones have not. The main
difference between the two platforms is the `gtar` version used so let's
always just use the formula on both platforms.
While we're here, clear up the ordering and comments a little on the
reproducible `tar` arguments so that it's easier to compare with the
reproducible builds archives documentation.
Fixes error seen in Homebrew/homebrew-core#138452.
`DevelopmentTools.default_compiler` can return a `Symbol` like `:clang`.
Make sure its result can be fed to `DevelopmentTools.locate`.
Signed-off-by: Ruoyu Zhong <zhongruoyu@outlook.com>
Having this would have been, or would be, useful on multiple occassions:
- Homebrew/homebrew-core#94724
- Homebrew/homebrew-core#136551
- #15372
I think it's time that we added this back.
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.
Many (~60) formulae in Homebrew/core set this manually to prevent the
`openssl` Rust crate from vendoring OpenSSL.
Let's make handling this simpler by setting it globally 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`.
