Sparc64 support

[Marius Strobl]

On Tue, Aug 11, 2015 at 11:02:03AM -0700, John Baldwin wrote:
> On Saturday, August 08, 2015 03:56:10 AM Baptiste Daroussin wrote:
> > On Fri, Aug 07, 2015 at 04:54:46PM -0700, Adrian Chadd wrote:
> > > Hi,
> > > 
> > > I've tested it with mips/mips64. It works out mostly okay. There are
> > > still rough edges, because in the mips world we have different
> > > defaults in our base system gcc to what the current toolchain expects.
> > > But at least for mips/mips64 it spits out a kernel and binaries that
> > > work.
> > > 
> > > What I did to make the MIPS bits call the external toolchain:
> > > 
> > > make <existing options> NO_WERROR=1 CROSS_TOOLCHAIN=mips-gcc buildworld
> > > 
> > > .. so in theory the sparc64 stuff may just be:
> > > 
> > > pkg install sparc64-gcc sparc64-xtoolchain-gcc
> > > make <existing stuff> NO_WERROR=1 CROSS_TOOLCHAIN=sparc64-gcc buildworld
> > > 
> > When I added the cross toolchain it was first tested on sparc64 and people
> > reported that it built and run fine with it.
> > 
> > This was with gcc 4.9, I haven't tested with 5.2
> 
> Should we perhaps looking at switching the default toolchain for sparc64 to
> external similar to how we require external binutils for aarch64?
> 

If you:
o created and are willing to maintain long-term support system toolchain
  ports (the regular upstream binutils and GCC releases are way too much
  of a moving target to justify their existence alone, i. e. I cannot
  remember a single in-tree toolchain update where newly introduced bugs
  in binutils and/or GCC did not cause regressions like C++ exceptions
  no longer working on any of !x86 at that time, kernel modules no longer
  working on sparc64, etc.),
o ensured release building works with the external toolchain, and
o fixed the chicken and egg problem of obtaining a system toolchain on
  the cross-built target bapt@ pointed out,
then: yes.

Marius