Hacker News Reader

Comment by cbmuser | Hacker News Reader

Why don't they just upgrade GCC to a more recent version. GCC still actively supports SPARC to this date and Rust support is also present and while not perfect, it definitely works.

So, while I don't really have a problem with removing SPARC support from Illumos which I wouldn't be using on SPARC systems anyway, the reasons mentioned in the document aren't convincing me at all.

FWIW, we still support sparc64 in Debian Ports:

> https://cdimage.debian.org/cdimage/ports/current/

View on HN

Because it's not a stock gcc. It's specially modified to do things quite differently on SPARC. If it was a case of "just" upgrading we would have done it long ago.

As one of approximately 2 people who actually build illumos on SPARC, I can testify that the whole thing is enough of a maintenance burden that it's causing major problems.

(And I'll just fork a copy and use that; it's not as though the SPARC ecosystem is a moving target.)

> (And I'll just fork a copy and use that; it's not as though the SPARC ecosystem is a moving target.)

This was actually one of my first questions on seeing the announcement - is Tribblix SPARC going to continue, or will this upstream change eventually EOL that as well?

Tribblix SPARC will continue. While you lose any new features that go into illumos upstream, at least you don't keep getting broken by changes going into illumos upstream.

(This isn't a commitment for all time, naturally. At some point the SPARC hardware I have will stop working. But it turns out to be solidly built and impressively reliable.)

So for the foreseeable future you intend to just freeze SPARC Tribblix on the last Illumos to support SPARC? I suppose it should stay ABI compatible with other components ~forever, so that shouldn't even hold back other pieces of the system.

Pretty much it, yeah. If there's anything useful upstream then it will get pulled in, and there's a still a lot of worthwhile cleanup of SPARC, but the kernel will be essentially frozen.

I hope Debian manages to keep sparc64 in Debian Ports. Just last night, I was fixed an alignment portability issue for e2fsprogs which only showed up on sparc64. The "non-portable" code worked just fine on all of the officially supported Debian architectures, and the only one where one of the alignment problem showed up was sparc64[1]. (Two of the alignment problems did show up when running a 32-bit arm chroot on a 64-bit arm kernel, but one of them, a failure in the regression test j_recovery_fast_commit, only be reproduced on sparc64.)

Sparc64 support is rocky; yes, it has a modern gcc, but stack unwinding in gdb is totally broken. (Not sure if that's a gdb or a gcc problem, but just try building some trivial program where main() calls some trivial function, and then try setting a breakpoint inside that function, and then try getting a stack trace.) This made finding the root cause of the alignment bug-induced crash much harder, but at least sparc64 served as a canary in the coal mine. Supporting niche architectures is great from a software quality perspective.

[1] https://buildd.debian.org/status/fetch.php?pkg=e2fsprogs&arc...

How would upgrading GCC help with the problem that they don't have SPARC machines available for building Illumos?

It wouldn't, but they state that one of the benefits of dropping SPARC is being able to "[retire] the now-ancient GCC 4.4.4 shadow compiler that remains chiefly to support the SPARC platform"

I'm guessing the problem isn't that newer GCC lacks SPARC support, but that their (now very old and bitrotted) SPARC support relies on some kind of undefined behavior or nuance of GCC 4 that prevents newer versions from building the kernel.

Illumos is a BSD, so perhaps, like other BSDs, they don't want to rely on GPLv3 projects like (current) gcc.

Illumos is a fork of Solaris, itself a UNIX System V derived OS, very much not a BSD, though taking some code from BSD. I'm not sure what license they make new additions under, but the core is CDDL licensed and not BSD licensed, anyway.

(side tangent FWIW, NetBSD has no qualms with using GPLv3 GCC, only Free/Open do)

(Edit for another historical tangent: Sun helped create System V release 4, which specifically combined element of older SysV with BSD. Additionally, Solaris/"SunOS 5"'s predecessor SunOS 4 was a straight-up BSD. So Solaris is a pretty BSD-y UNIX, in a way...)

NetBSD can optionally be built with LLVM/Clang. It can be cross-compiled using either toolchain.

Well, yes -- it's nice and portable like that. I think at some point they got it building with PCC and TCC too?

My point is unlike the other BSDs they haven't made a point of deprecating/removing GCC from the source tree, or even using LLVM by default where they can. For third parties worried about GPLv3, you can easily delete all GPLv3 code with a rm -rf src/external/gpl3 :)

LLVM doesn't support all the CPU architectures that GCC does, ones missing include 68k, VAX and SH3.

LLVM recently got a m68k backend. It's still marked experimental, so distros likely aren't enabling it yet. But it's seeing active developments from hobbyists. Main author of the m68k just had a book on LLVM published.

Illumos is from the System V family tree, as it is a direct descendant of OpenSolaris.

While I don't follow Illumos closely, I know that there was a project to remove the dependency on the Sun Studio compiler suite, so it's possible that the reliance on the old gcc version has something to do with that.

Well, they could reach out to the Debian or Gentoo community and ask for help. We would be happy to help them.

Reply on news.ycombinator.com