- 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`.
Fixes#18556 by using RUSTC_WRAPPER instead of setting RUSTFLAGS directly.
This allows Homebrew's optimization flags to coexist with .cargo/config.toml
settings, preventing build failures when projects have their own Rust
configuration.
- Add rustc_wrapper shim that clears RUSTFLAGS and prepends HOMEBREW_RUSTFLAGS
- Update both std and super environments to use RUSTC_WRAPPER
- Store Homebrew's rustflags in HOMEBREW_RUSTFLAGS instead of RUSTFLAGS
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-Authored-By: Claude <noreply@anthropic.com>
Co-authored-by: Carlo Cabrera <github@carlo.cab>
While filing https://github.com/Homebrew/brew/issues/20379, I lost where I was because I followed the given instruction. Instead, let's use pushd/popd so the user is returned to their pwd if the git operations succeed.
The library_paths method was using readlines which could leave file
descriptors open due to Ruby's garbage collection behavior. When
processing many packages during 'brew upgrade' or 'brew linkage',
this caused "Too many open files" errors on Linux systems.
Changes:
- Replace readlines with explicit file.open block to ensure proper closure
- Add caching to avoid repeatedly reading /etc/ld.so.conf during a session
- Cache included files as well to optimize recursive include processing
Fixes: #19866, #20302, #19177, #20223🤖 Generated with [Claude Code](https://claude.ai/code)
Co-Authored-By: Claude <noreply@anthropic.com>
