Sparc64 support

[Bill Sorenson]

I just spent a day building clang36 from ports on one of my idle sparc
machines, and it builds a working ubench binary. I'm going to see if I can
build some ports with it but thus far the latest clang seems at least
superficially functional on sparc. I know when I tired many moons ago,
clang built binaries would instantly dump.

-Bill Sorenson

On Fri, Aug 7, 2015 at 2:53 PM, John Baldwin <jhb at freebsd.org> wrote:

> On Wednesday, August 05, 2015 02:10:34 PM Bill Sorenson wrote:
> > I'm one of probably a few users of FreeBSD and OpenBSD on multiple
> > platforms left and I thought I'd share some of my experience with BSD on
> > some of the lesser used platforms.
>
> Realistically, the major potential bump in the road for sparc64 is the
> toolchain.  GCC 4.2.1 is getting really long in the tooth and as a
> Project we want to drop it as our system compiler.  I can't tell you
> when that will happen, but it will eventually.  That means that all of
> our supported platforms will either have to work with clang, or they will
> need to use an external GCC toolchain (of more recent vintage).  Ensuring
> that one of these routes work for sparc64 will make it much easier for
> sparc64 to stay in the tree without inhibiting other work.
>
> My understanding is that the most recent clang in HEAD can at least build
> and install on sparc64, but that programs built with it might segfault,
> etc.  If you are up for debugging those issues then that is one approach.
> I do think that clang works on Linux/sparc64, so that these should be
> FreeBSD bugs moreso than clang/llvm bugs (but I can't promise that).
>
> In theory we have bits in our build system to use an external toolchain
> for building a system.  I haven't worked with them but I have seen others
> talk about them (e.g. imp@ and bapt@).  Getting the recipe down for how
> to do it and testing that the system works with recent versions of
> GCC is what is missing there I think (so that there are instructions of
> 'install port foo', 'stick this in /etc/make.conf', or 'put this on the
> command line to buildworld', etc.).  Of course, testing that the resulting
> binaries also work correctly would also be good. :)
>
> --
> John Baldwin
>