staging/xback/toolchain, branch master

toolchain: keep the build path out of the target libraries

2026-09-22T16:46:30Z

gcc builds the target libraries with CFLAGS_FOR_TARGET, which carries no prefix map. __FILE__ therefore expands to an absolute path, and assert in libstdc++ and the ryu code put seven of them into .rodata, where the strip before packaging cannot reach them. The libstdcpp6 package differs between two builds in different directories, and so does every image that ships it. The published package shows the same thing. libstdcpp6-14.4.0-r5.apk of bcm47xx/mips74k holds /builder/shared-workdir/build/build_dir/toolchain-mipsel_74kc_gcc-14.4.0_musl/gcc-14.4.0/libstdc++-v3/src/c++11/debug.cc so no rebuild of that package can match today. iremap is called with BUILD_DIR for the kernel, with PKG_BUILD_DIR for a package and with STAGING_DIR for the target headers. The toolchain build directory has no such call. Add one for the three FOR_TARGET flag sets. The replacement keeps the build_dir element, because the last element of the toolchain build directory and of the toolchain staging directory is the same string and one replacement for both would make the two roots indistinguishable. Tested with two bcm47xx/mips74k trees whose directory names differ in length. The shipped libstdc++.so.6.0.33 holds no absolute path any more and the libstdcpp6 package is now identical in both trees. It differed by 165 bytes before. The toolchain staging directory still appears in the debug information of the same library, 244 times. Those are DWARF include directories, they do not survive the strip, and no shipped file carries them. Signed-off-by: John Crispin

toolchain: gcc: fix SHF_MERGE check with binutils 2.46

2026-09-14T11:09:01Z

gcc probes the assembler for section merging support with '.section .rodata.str, "aMS", @progbits, 1', which on 32-bit arm the '@' comment character truncates. gas 2.46 no longer accepts that form, and since gcc's %progbits fallback probe reuses the same autoconf cache variable it never runs, so HAVE_GAS_SHF_MERGE ends up 0. String literals then land in one plain .rodata per translation unit instead of per-function mergeable sections, --gc-sections can no longer drop the strings of dead functions, and the am335x SPL grows by 9.5 kB past its 110592 byte budget. Backport the upstream fix, which gives the fallback probe its own cache variable. It is in GCC 15 and later. Fixes: 82f26df15c56 ("toolchain: binutils: change default to 2.46") Signed-off-by: Daniel Golle

Revert "toolchain: drop $(REVISION) from GCC version"

2026-07-29T07:14:05Z

This reverts commit 9292f32fd96dc00b7c3f34a028d1fc41a4fcb6d2. Downstream patches may change the output. If the GCC version doesn't incooperate the patches somehow (hash, git commit, ...), ccache may not invalidate existing cache. Revert this until a cleaner solution is found. Signed-off-by: Paul Spooren

toolchain: drop $(REVISION) from GCC version

2026-07-23T11:20:23Z

Storing the ever changing revision in the GCC binary may result in leakage in package builds. If two equal GCC versions build the same package version with different OpenWrt revisions, the package becomes unreproducible. Solve this by dropping the revision. Below is an example of the `cni` package: │ ├── readelf --wide --decompress --string-dump=.comment {} │ │ @@ -1,4 +1,4 @@ │ │ │ │ String dump of section '.comment': │ │ - [ 0] GCC: (OpenWrt GCC 14.4.0 r35470-1b2aeb4f8a) 14.4.0 │ │ + [ 0] GCC: (OpenWrt GCC 14.4.0 r35485-0f256a0a7a) 14.4.0 Signed-off-by: Paul Spooren

toolchain: gcc: update GCC 14 to 14.4

2026-06-29T09:40:20Z

Changelog: https://gcc.gnu.org/gcc-14/changes.html Remove upstreamed patches: - patches-14.x/004-libcody-Make-it-buildable-by-C-11-to-C-26.patch[1] - patches-14.x/005-include-memory.patch[2] - patches-14.x/240-libsanitizer-fix-termio-glibc-2.40.patch[3] All other patches are automatically refreshed. [1] https://gcc.gnu.org/cgit/gcc/commit/?h=releases/gcc-14.4.0&id=daa3e1ead791bc58208043cfc4595ba1a78cdd34 [2] https://gcc.gnu.org/cgit/gcc/commit/?h=releases/gcc-14.4.0&id=046776dac7cc74bdbab36f450af80644a045858a [3] https://gcc.gnu.org/cgit/gcc/commit/?h=releases/gcc-14.4.0&id=f0feb51ff40553643c582ec9c3ca7f293721ddc8 Signed-off-by: Shiji Yang Link: https://github.com/openwrt/openwrt/pull/23950 Signed-off-by: Robert Marko

toolchain: gcc: update GCC 15 to 15.3.0

2026-06-27T09:54:03Z

Release Notes: https://gcc.gnu.org/gcc-15/changes.html Removed upstreamed: toolchain/gcc/patches-15.x/004-libcody-Make-it-buildable-by-C-11-to-C-26.patch [1] [1] https://github.com/gcc-mirror/gcc/commit/1f0224e8ddb3d3d0bf4c7a11769b193a4df5cc37 Signed-off-by: Konstantin Demin Link: https://github.com/openwrt/openwrt/pull/23771 Signed-off-by: Hauke Mehrtens

toolchain: binutils: fix default version selection

2026-06-26T17:04:24Z

Fixes: 82f26df15c56 ("toolchain: binutils: change default to 2.46") Signed-off-by: Shiji Yang Link: https://github.com/openwrt/openwrt/pull/23952 Signed-off-by: Jonas Jelonek

toolchain: binutils: change default to 2.46

2026-06-26T12:51:16Z

Change default to latest upstream release. Link: https://github.com/openwrt/openwrt/pull/23907 Signed-off-by: Jonas Jelonek

toolchain: binutils: partially revert commit 525a1e94b343 "fix update to 2.45.1"

2026-06-17T06:52:03Z

Commit eac927fadf07 "toolchain: binutils: simplify patch management" being applied after commit 525a1e94b343 "toolchain: binutils: fix update to 2.45.1" effectively disables patching binutils 2.45.1 in OpenWrt. Fixes: 525a1e94b343 "toolchain: binutils: fix update to 2.45.1" Signed-off-by: Konstantin Demin Link: https://github.com/openwrt/openwrt/pull/23773 Signed-off-by: Jonas Jelonek

toolchain: binutils: update to 2.46.1

2026-06-17T06:52:03Z

Release Notes: https://sourceware.org/pipermail/binutils/2026-June/149568.html Signed-off-by: Konstantin Demin Link: https://github.com/openwrt/openwrt/pull/23773 Signed-off-by: Jonas Jelonek