ruby-macho chokes on changing duplicate RPATHs, so we need to strip the
duplicates before trying to relocate them.
This continues #11405. We need this to unblock
Homebrew/homebrew-core#91224.
While we're here, let's get rid of `HOMEBREW_RELOCATE_RPATHS`. We've
been using it for nearly a year with essentially no problems (barring
`pdnsrec`), so I think it is safe to do unconditionally.
Upon reflection, I realised that this is probably a bug in `ruby-macho`,
and should be fixed there instead.
Needs https://github.com/Homebrew/ruby-macho/pull/362.
This reverts commit e8b5eb7e42c925b7cc10c78a029b8c70e4d7965b.
Java-dependent formulae produce different bottles on macOS and Linux
because they have different values for `JAVA_HOME` (`opt_libexec` vs
`opt_libexec/"openjdk.jdk/Contents/Home"`).
Let's handle this difference by using the placeholder
`@@HOMEBREW_JAVA@@` in a bottle, like so:
#!/bin/bash
JAVA_HOME="${JAVA_HOME:-@@HOMEBREW_JAVA@@}" exec "@@HOMEBREW_CELLAR@@/clojure/1.10.3.998/libexec/bin/clojure" "$@"
While this should never be necessary for per-OS bottles, this could be useful for :all bottles where the OS it was built on uses a Perl version that doesn't exist on all macOS versions.
Homebrew/homebrew-core#77623 revealed two bugs. One in `ruby-macho`,
which turns out to be unable to delete duplicated `RPATH`s. This was
fixed with `ruby-macho` 2.5.1.
The second, which this commit fixes, is in our handling of duplicate
`RPATH`s. Since we iterate over each `RPATH`, attempting to relocate the
first duplicate fails since it will no longer exist after having
relocated the original.
Running `brew bottle` changes dylib IDs, install names, and rpaths into
placeholders for the bottle, creates a bottle tarball, and then changes
the placeholders back to their correct values.
With my refactoring in #11358, the behaviour of this relocation changed:
dylib IDs would no longer be changed back from placeholders into their
correct values after the creation of the bottle tarball.
- remove usage on macOS as we don't care about it there
- don't error out on incompatibility but still store stdlib on Linux
- remove (now) unused methods
During the changes to macho file relocation refactoring
in #3101, #3138, and #3139,
the number of arguments to the mach::change_install_name
function changed from 3 to 2, but
there was still an instance of the function being called
with the wrong number of arguments.
