i686-elf-binutils

Cross-binutils for the i686-elf target (bare-metal OS dev, paired informally with i686-elf-pcc-git/i686-elf-gcc-style toolchains). Tracks upstream GNU binutils releases directly (not a distro fork) via .nvchecker.toml:

source = "regex"
url = "https://ftp.gnu.org/gnu/binutils/"
regex = "binutils-([0-9]+\\.[0-9]+)\\.tar"

Note the regex only captures bare MAJOR.MINOR (matches binutils-2.47.tar.xz but not binutils-2.46.0.tar.xz, since .0.tar != .tar) – fine as long as upstream’s tarball name matches pkgver exactly, which has held so far.

2026-07-27: 2.45-2 -> 2.47-1

Routine pkgver bump (2.47 confirmed real via curl listing of ftp.gnu.org/gnu/binutils/, sits alongside 2.46.0/2.46.1/2.45.1 etc., not bait). updpkgsums re-downloaded and got a matching sha256 to x86_64-elf-binutils’s 2.47 update run same day (same upstream tarball, different target configure flags) – good cross-check when bumping both cross- binutils packages in the same pass.

Test build via extra-x86_64-build succeeded; namcap flags a long list of pre-existing lint warnings/errors (cross-directory hardlinks between usr/i686-elf/bin/* and usr/bin/i686-elf-*, SPDX license string) that are inherent to how this PKGBUILD lays out a cross-toolchain and were already present at 2.45-2 – not new regressions, not worth chasing.

Checked: no i686-elf-gcc/i686-elf-elf-gcc-style compiler package exists in this tree. Only maintained/i686-elf-pcc-git depends on this package, via a plain unversioned depends= – binutils userspace tools aren’t a linked ABI a compiler build depends on, so a binutils version bump alone never requires rebuilding/pkgrel-bumping a dependent compiler package.