Sparc64 doesn't care about you, and you shouldn't care about Sparc64

John Baldwin jhb at
Wed Nov 11 18:46:21 UTC 2015

On Wednesday, November 11, 2015 04:07:35 PM Brian McGovern wrote:
> I have to step in on Jordan's side on this one. As a recently-former lab admin (June), we were - and I assume continue to - chucking Sun Sparc hardware as fast as we can EOL the products which run on the platform, and to the best of my knowledge, we haven't bought new gear since Oracle bought Sun. I think I still have an SB150 sitting in a closet collecting dust for the emergency case which is predestined to emergency at some point, but we're not even considering giving the boxes another life as second tier hardware - the x86/64 space offers far superior metrics in terms of price/performance/support/replacement parts.
> This, of course, means that our customers will be eventually follow suit as they do their next round of upgrades. While this means there will be a ton of Sparc64 hardware around at low prices, I have no doubt it'll be a niche community, like BETAMAX, Laserdisc, and HD-DVD before...
> If there is someone who loves this platform enough to keep it going single-handedly, or nearly so, that's one thing. If the discussion is to divert project resources to keep it alive just because its one more platform, I have a laundry list of things that I suspect will have a bigger impact on the broader x86 (and even ARM) community; then again, I expect just about everyone has such a list.

This last question is an important one I think.  What is the actual cost to
the project to let sparc64 remain Tier-2?  That means we aren't committed to
building packages, so that mostly lets Sean off the hook.

The biggest hang up I can see is the question of toolchain.

On the question of toolchain I think GCC 4.2 continues to become incredibly
less useful.  If we could have an 11 without GCC 4.2 that would be ideal.
However, clang is only production-viable on x86 right now.  Even lldb doesn't
work on i386 and only works on amd64.  If your argument for tossing sparc64
is GCC 4.2 then if you are logically consistent you have to toss a whole lot
of other stuff as well.  (Even clang on amd64 is still using binutils ld)

Realistically I think FreeBSD needs to support two sets of toolchains:
clang and modern (GPLv3) GCC/binutils.

I think it is a laudable goal to have the option of a GPL-free base system,
but I think we should also make it an option to use a modern GCC toolchain.

For platforms that depend on GCC 4.2 I think we should be moving them to
using newer GCC in some fashion.  That is relevant for several architectures
that we definitely want to keep going forward, not just sparc64, and it's a
problem we need to solve regardless.  Once that is addressed it is not clear
to me what drain on project resources sparc64 is.

John Baldwin

More information about the freebsd-sparc64 mailing list