`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>
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`.
- Make copying to `*_names.before.txt` the responsibility of `update.sh`
(unless the file doesn't exist at all). This provides the added
benefit of allowing the inspection of the before/after state after
running a `brew update` rather than both files always being identical
at this point.
- State `No changes to formulae or casks.` on macOS.
- Rename and flip `updated_formula_report` to `auto_update`; this naming
was confusing every time.
- Only display the `You can upgrade with...` messaging if we're not
auto-updating as sometimes it will be displayed before the commands it
references (e.g. `upgrade`, `outdated` or an `install` that proceeds
to upgrade these formulae).
Fixes https://github.com/Homebrew/brew/issues/15065
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.
