All I want is just a collection of #binutils, #GCC, #llvm+#clang, #glibc and #musl that are "free standing" / relocatable, which I can pack into a #squashfs image to carry around to my various development machines.
You'd think that for something as fundamental as compiler infrastructure with over 60 years of knowledge, the whole bootstrapping and bringup process would have been super streamlined, or at least mostly pain free by now.
Yeah, about that. IYKYK
Linux 6.16 will need GCC 8 and Binutils 2.30 to build.
#Linux #Kernel #LinuxKernel #Computers #Laptops #TechNews #TechUpdates #GCC #Clang #LLVM #Binutils
https://officialaptivi.wordpress.com/2025/06/01/linux-6-16-needs-gcc-8-and-binutils-2-30/
Linux 6.16 needs GCC 8 and Binutils 2.30
The upcoming version of Linux now needs at least GCC 8 and GNU Binutils 2.30 to be able to successfully build, because this was needed to remove all legacy code that provided workarounds for build systems prior to GCC 8, which became a maintenance burden. Previously, GCC 5 and Binutils 2.25 were required to build Linux, and the latest version, 6.15, had this requirement before 6.16 increased it.
GCC 8 and Binutils 2.30 brought new features that Linux 6.16 needed, while LLVM Clang 13 was the minimum requirement for Linux in case you’ll need to use LLVM instead of the legacy GCC.
You can see the merge request below.
See merge requestThe reasoning for this minimum version requirement bump is here:
x86 already uses gcc-8 as the minimum version, this changes all other architectures to the same version. gcc-8 is used is Debian 10 and Red Hat Enterprise Linux 8, both of which are still supported, and binutils 2.30 is the oldest corresponding version on those.
Ubuntu Pro 18.04 and SUSE Linux Enterprise Server 15 both use gcc-7 as the system compiler but additionally include toolchains that remain supported.
With the new minimum toolchain versions, a number of workarounds for older versions can be dropped, in particular on x86_64 and arm64. Importantly, the updated compiler version allows removing two of the five remaining gcc plugins, as support for sancov and structeak features is already included in modern compiler versions.
I tried collecting the known changes that are possible based on the new toolchain version, but expect that more cleanups will be possible.
Since this touches multiple architectures, I merged the patches through the asm-generic tree.”
Sourceware Survey 2025 Results
In the end we got 103 (!) responses with a nice mix of developers, users and maintainers from various hosted projects.
https://sourceware.org/survey-2025
#binutils #cygwin #dwarfstd #elfutils #gcc #gdb #glibc #libabigail #newlib #systemTap #valgrind #bzip2 #libffi #dwz #debugedit #gnupoke #bunsen #lvm2 #annobin #gnu-gabi #cgen #kawa #insight #pacme
ltmain.sh isn't a source file, it's the compiled output of a bunch of m4 code from libtool. The version of ltmain.sh in #GNU #binutils does not correspond to any version of the libtool sources (release tarballs or libtool.git). We don't have the Complete Corresponding Source to binutils' ltmain.sh! #GPLviolation :P
(It has a --no-finish flag that no libtool sources have ever had.)
@goku12 ta, I heard about that more broadly and keen to give it a whirl from OpenRC perspective.
Hit a blocker on the migration process though, can't rebuild binutils under new profile.
https://forums.gentoo.org/viewtopic-p-8821293.html
Hope to work through the problem soon though.
Toolchain Necromancy: Past Mistakes Haunting ASLR
“Starting from 2001 and continuing until 6 years ago with version 2.32, #binutils' ld linker set too large of an alignment on ELF binary sections. With a #Linux kernel >= 5.10 or glibc >= 2.35, binaries/libraries that were built with the older toolchain act as timebombs against #ASLR, making brute-force attacks easier on 64-bit binaries and reducing randomness to nothing in some cases for 32-bit binaries.”
https://grsecurity.net/toolchain_necromancy_past_mistakes_haunting_aslr
