20 ms·

> gcc(1) - updated to 12.5.0. Anyone know why they are still on such an old version? The latest version is 16.1.

mghackerlady 2mo ago
They don't like GPLv3. The other BSDs used similarly old versions until they moved to clang, but netbsd is pretty tied to the gnu toolchain and aims to be as portable as possible, so they kinda have to stick to gcc
- microtonal 2mo ago
  But the licensing didn't change between gcc 12 and gcc 16, so that doesn't seem like a good explanation?
  - PuercoPop 2mo ago
    It is not a good explanation because that is not the reason. That reason is for Mac OS. I don't know the details, but BSDs normally modify the GCC version they use. IIRC OpenBSD used to use GCC 2.95 for years. Porting NetBSD base to compile with a newer GCC version is not as simple as a version bump. My guess is that they haven't prioritized that work yet. Patches welcome!
    - brynet 2mo ago
      > IIRC OpenBSD used to use GCC 2.95 for years. 2.95.3 and 3.3.6, both have now been retired in favour of gcc4. The majority use clang now, though.
- hexagonwin 2mo ago
  wasn't that around gcc4 or something era? gcc12 is pretty new
  - brynet 2mo ago
    Indeed, 4.2.1 was the last GPLv2 version. OpenBSD still uses it (w/ patches) for a few platforms, for example. /bsd.own.mk:GCC4_ARCH=alpha hppa m88k sh sparc64 The rest have already been migrated to LLVM/Clang 22 by default (except sparc64 below, that's experimental). ./bsd.own.mk:CLANG_ARCH=aarch64 amd64 arm i386 mips64 powerpc powerpc64 riscv64 sparc64
- washbear 2mo ago
  This is not the reason. We created this branch in July 2025 (GCC 12.5 was released on 11 July, 2025) and spent a year stabilizing it. A new system compiler is considered far too much of a risky, incompatible change to backport. Especially since lots of C code no longer compiles with GCC 14+ without significant changes. Each time we upgrade the system compiler, it requires extensive work to keep all of our supported architectures in working order, and adjust our code for compatibility.
  - ranger_danger 2mo ago
    Why would the C code no longer compile if it conforms to the spec?
    - stonogo 2mo ago
      There is more than one C specification, and with each new release of GCC several things that used to emit warnings are newly treated as errors.
      - ranger_danger 2mo ago
        but if the correct standard is specified as an option, shouldn't that prevent conformant applications from failing to compile in newer versions?
        stonogo 2mo ago
        Sure, that's one approach. Testing those changes takes time when you're working on a whole operating system and a ports tree. More time than cutting a new gcc release, as it turns out.
        hulitu 2mo ago
        > shouldn't that prevent it should. It doesn't.
    - seabrookmx 2mo ago
      "The spec" is loose in places and is full of undefined behavior which can change from compiler to compiler. Very low level code tends to hit these types of issues much more than application code would. But these types of issues are even common in large userspace codebases.
spijdar 2mo ago
It's almost certainly due to supporting platforms like VAX and other, more exotic ISAs. GCC can have weird regressions [0] in "less tested" architectures, so I presume they use a single, known good release across all platforms for consistency's sake. [0] GCC still supports PDP-11, for example, but for a while modern GCC had some major codegen bugs. Last I checked, the maintainer had made heroic efforts to fixing the bugs, but that's just an example of where bitrot silently renders a target unusable.
- washbear 2mo ago
  This is partly the reason, the other reason is that we created this branch in July 2025 (GCC 12.5 was released on 11 July, 2025) and spent a year stabilizing it. A new system compiler is considered far too much of a risky, incompatible change to backport. Especially since lots of C code no longer compiles with GCC 14+ without significant changes.
jmclnx 2mo ago
gcc 15.1 is in pkgsrc 2026Q2: gcc15-15.2.0nb1 - The GNU Compiler Collection (GCC) - 15.0 Release Series As others said, I think it has to do with all the platforms NetBSD supports.

They don't like GPLv3. The other BSDs used similarly old versions until they moved to clang, but netbsd is pretty tied to the gnu toolchain and aims to be as portable as possible, so they kinda have to stick to gcc

microtonal 2mo ago
But the licensing didn't change between gcc 12 and gcc 16, so that doesn't seem like a good explanation?
- PuercoPop 2mo ago
  It is not a good explanation because that is not the reason. That reason is for Mac OS. I don't know the details, but BSDs normally modify the GCC version they use. IIRC OpenBSD used to use GCC 2.95 for years. Porting NetBSD base to compile with a newer GCC version is not as simple as a version bump. My guess is that they haven't prioritized that work yet. Patches welcome!
  - brynet 2mo ago
    > IIRC OpenBSD used to use GCC 2.95 for years. 2.95.3 and 3.3.6, both have now been retired in favour of gcc4. The majority use clang now, though.
hexagonwin 2mo ago
wasn't that around gcc4 or something era? gcc12 is pretty new
- brynet 2mo ago
  Indeed, 4.2.1 was the last GPLv2 version. OpenBSD still uses it (w/ patches) for a few platforms, for example. /bsd.own.mk:GCC4_ARCH=alpha hppa m88k sh sparc64 The rest have already been migrated to LLVM/Clang 22 by default (except sparc64 below, that's experimental). ./bsd.own.mk:CLANG_ARCH=aarch64 amd64 arm i386 mips64 powerpc powerpc64 riscv64 sparc64
washbear 2mo ago
This is not the reason. We created this branch in July 2025 (GCC 12.5 was released on 11 July, 2025) and spent a year stabilizing it. A new system compiler is considered far too much of a risky, incompatible change to backport. Especially since lots of C code no longer compiles with GCC 14+ without significant changes. Each time we upgrade the system compiler, it requires extensive work to keep all of our supported architectures in working order, and adjust our code for compatibility.
- ranger_danger 2mo ago
  Why would the C code no longer compile if it conforms to the spec?
  - stonogo 2mo ago
    There is more than one C specification, and with each new release of GCC several things that used to emit warnings are newly treated as errors.
    - ranger_danger 2mo ago
      but if the correct standard is specified as an option, shouldn't that prevent conformant applications from failing to compile in newer versions?
      - stonogo 2mo ago
        Sure, that's one approach. Testing those changes takes time when you're working on a whole operating system and a ports tree. More time than cutting a new gcc release, as it turns out.
      - hulitu 2mo ago
        > shouldn't that prevent it should. It doesn't.
  - seabrookmx 2mo ago
    "The spec" is loose in places and is full of undefined behavior which can change from compiler to compiler. Very low level code tends to hit these types of issues much more than application code would. But these types of issues are even common in large userspace codebases.

spijdar 2mo ago

It's almost certainly due to supporting platforms like VAX and other, more exotic ISAs. GCC can have weird regressions [0] in "less tested" architectures, so I presume they use a single, known good release across all platforms for consistency's sake. [0] GCC still supports PDP-11, for example, but for a while modern GCC had some major codegen bugs. Last I checked, the maintainer had made heroic efforts to fixing the bugs, but that's just an example of where bitrot silently renders a target unusable.

washbear 2mo ago
This is partly the reason, the other reason is that we created this branch in July 2025 (GCC 12.5 was released on 11 July, 2025) and spent a year stabilizing it. A new system compiler is considered far too much of a risky, incompatible change to backport. Especially since lots of C code no longer compiles with GCC 14+ without significant changes.

jmclnx 2mo ago

gcc 15.1 is in pkgsrc 2026Q2: gcc15-15.2.0nb1 - The GNU Compiler Collection (GCC) - 15.0 Release Series As others said, I think it has to do with all the platforms NetBSD supports.