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

Anna Wilcox AWilcox at
Tue Nov 10 04:22:34 UTC 2015

Hash: SHA256

On 08/11/15 11:16, Sean Bruno wrote:
> On 11/08/15 07:55, Marius Strobl wrote:
> > Unlike x86, sun4u and sun4v CPUs are only designed to be backwards
> > compatible as far as the userland is concerned,
> > host-PCI{,e}-bridges aren't compatible etc. So the kernel side
> > always needs work and it simply isn't a matter of "testing" newer
> > CPUs and models to work. Thus, the hardware is needed for
> > developing support, see also below.
> > I'm not sure at which point I'd speak of people "clamoring" for
> > support of some hardware; f. e. there also isn't a request for the
> > graphics of Haswell and later Intel CPUs to be supported on the
> > mailing lists every other day but you'll certainly agree that many
> > are waiting for it. Now there likely are fewer people looking
> > forward for later sun4u and sun4v processors getting supported but
> > there definitely are people asking for it, just have a look at the
> > lists.
> Now is the time for those users/people to step up and "clamor" for it.
>  The example of Haswell graphics is a good point.  There is an active
> developer working on the support with instructions on how to use the
> test branch in github.  We don't have an equivalent project ongoing
> for the Sparc64 target AFAIK.  I welcome being proven wrong here.
> > I don't see why sparc64 would be "the obvious odd arch" in that
> > regard. The real problem is switching an architecture for which
> > clang might have gotten en par with GCC after clang was changed to
> > require C++11 for bootstrap. Given that clang was only the default
> > on arm and x86 at that point in time, we are now stuck without an
> > in-tree upgrade path on all other architectures. Granted, that
> > might be lesser a problem on mips as these machines typically don't
> > have enough CPU and RAM that self-hosting would be interesting in
> > the first place. That still puts sparc64 into the same boat as
> > powerpc and powerpc64, though.
> It's "obvious" to me from reading mailing lists and IRC chatter.  This
> is a poor justification on my part as it requires participating in
> these to see the "obviousness" of the argument.
> I am personally pursuing clang enabled MIPS builds.  Others are moving
> the MIPS target to enable support for gcc from ports.  Powerpc
> developers have been working on clang and the clang intree is built
> and installed in the powerpc images.  From my impression, there hasn't
> been a similar push intree to do the same type of things for the
> Sparc64 target.  Am I wrong here?

Just as a further note, I had experimented in January of this year with
making a binary pkg mirror for sun4u using my (comparatively sad) Ultra
60 and a cross-build system.  Installation was fairly straightforward
but I was having issues bringing up Clang and was having many issues
trying to build "modern" packages using GCC 4.2.1.

See my blog for some insight:

Unfortunately, truth be told, I gave up after the Freenode IRC channel
gave me a whole heap of abuse and name-calling for trying to ask for any
support with the sparc64 port.  I couldn't find the documentation I
needed to keep going and nobody wanted to help.  If there are others
working on this and I am not alone after all, I will gladly pull the
Ultra 60 back on to my desk and do what I can to help out.  GCC 4.8 or
4.9 would be a huge, huge, huge improvement in particular.

- --arw
Version: GnuPG v2


More information about the freebsd-sparc64 mailing list