Fixes#13762.
There's still a bug in the GCC linkage check, but I'll need a bit more
time to work on a fix. This at least makes sure `brew doctor` will not
return the error in the issue linked above.
An executable that links against @rpath-prefixed dylibs must include at least
one runtime path. This will prevent issues like the one resolved in #91485.
Caveats:
1. This won't find executables that have only recursive dylib dependencies with
@rpath prefixes.
2. This makes no attempt to resolve @rpath, @executable_path or @loader_path
dylibs, or to verify the correctness of any LC_RPATH entries, or to
otherwise simulate dlopen logic.
3. Weakly-linked dylibs are still excluded from the search for broken linkage.
The scope is narrow in order to focus on this particular problem. It is meant
only as a sanity check.
refines PatchELF #runpath, #rpath #soname #interpreter
to return nil.
let Brew hard exits on PatchELF::PatchError.
Co-authored-by: Shaun Jackman <sjackman@gmail.com>
Co-authored-by: Mike McQuaid <mike@mikemcquaid.com>
Having HOMEBREW_PATCHELF_RB set in the ENV,
will conditionally install patchelf.rb gem,
use patchelf.rb in the above mentioned methods.
The installed vendored gems are listed in .gitignore
to maintain a clean state.
Some elf files (e.g. created by rust compiler) have INTERP header despite
their magic header denotes shared object instead of executable.
We should relocate the interpreter elf files as long as they have INTERP header.
This should fix the broken bottles for rust based formulae.
Some elf files like unittest files or memory dumps may not be completely
readable by readelf.
Readelf will fail after the following message:
readelf: Warning: possibly corrupt ELF header - it has a non-zero program header offset, but no program headers
This patches avoid these files when there is a non zero offset but no
program headers
