In #20424, we moved `HOMEBREW_RUSTFLAGS` to the end of the compiler
invocation, but didn't update the comment. Let's fix that.
While we're here, let's fix these `shellcheck disable`s.
If we pass it first, it can be overridden by other arguments passed on
the command line. We don't want that.
See discussion at Homebrew/homebrew-core#232566.
This needs to be handled more carefully. It probably works fine for
bottles built *after* this change was added, but it breaks bottles built
before this exclusion was added.
Let's remove it for now to limit the extent of the breakage.
- If a HEAD branch name isn't specified at all, then the user probably
wants to shortcut adding one by being told what the default branch for
the repo is. Otherwise they have to click the URL, look at the GitHub
UI, then type the branch name into `branch: "foo"` syntax.
On Linux, we occasionally see `EMFILE` ("too many open files") errors
especially when installing a large formula like `llvm`. Currently, this
can be reliably reproduced in a Homebrew/brew GitHub codespace (where
`ulimit -n` seems to be 1024 by default) with `brew install geeqie`,
with the following error message:
Error: Too many open files @ rb_sysopen - /home/linuxbrew/.linuxbrew/Cellar/llvm/20.1.8/bin/tblgen-lsp-server
The reason is that each instance of `PatchELF::Patcher` keeps the ELF
file open. We prepend the `ELFShim` module to the `Pathname` class and
cache the patcher as an instance variable, which means that the ELF file
remains open so long as the `Pathname` instance is still alive even if
we don't need to access the ELF metadata anymore. When performing
certain checks (e.g., linkage), we also store these `Pathname`
instances, so the number of open file descriptors simply keeps
increasing.
We can fix that by not caching the patcher and only use it when
necessary. We create a patcher instance whenever we need to read or
write ELF metadata, and reading of metadata is consolidated into the
existing `ELFShim::Metadata` class so that we don't repeatedly create
patcher instances.
A fix for a file descriptor leak issue in patchelf.rb has been submitted
at https://github.com/david942j/patchelf.rb/pull/48. Together with that,
this fixes#19177, #19866, #20223, #20302.
Having log files with extensions like `.cc` and `.cmake` is really
unfriendly to editor syntax highlighters and language servers. Let's try
to make sure these are opened as log files by adding a `.log` extension
to them.
- Since `head` must now specify a url and branch, the `head do` block
with only these stanzas can be condensed to the single-line
`head "url", branch: "branch"` format.
- There's a TODO on the "someday" list [1] to ensure that `head` Git
URLs always specify a branch.
- So I thought I'd automate this worry by adding an audit.
- Since `resource` block URLs tend to be pinned to SHAs, if indeed
they are Git URLs, this audit only applies to `head` URLs.
[1]: https://github.com/orgs/Homebrew/projects/5?pane=issue&itemId=98789749
We have multiple formulae (e.g. `ola`, `openvino`, `opencv`, `or-tools`,
`pytorch`) that seem to be broken by `patchelf.rb` on x86_64 Linux.[^1] The
common thread seems to be the presence of a `protodesc_cold` section in
the ELF header.
Let's avoid breaking these bottles by skipping relocation when a binary
file has a `protodesc_cold` section. It will probably hurt
relocatability of these bottles, but that's better shipping broken
binaries.
[^1]: https://github.com/Homebrew/homebrew-core/pull/210860#issue-2918569212
`HOMEBREW_FORCE_BREW_WRAPPER` can be used as a security/compliance
feature, but allowing it to be disabled by setting
`HOMEBREW_NO_FORCE_BREW_WRAPPER` leaves a pretty large hole in it that
allows it to be sidestepped.
Let's fix that by actually checking the path of the process that called
`brew`, and the verify that that path matches the configured value of
`HOMEBREW_NO_FORCE_BREW_WRAPPER`.
