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

[Warner Losh]

On Sun, Nov 8, 2015 at 2:45 PM, Ed Maste <emaste at freebsd.org> wrote:

> On 8 November 2015 at 20:46, Justin Hibbits <jrh29 at alumni.cwru.edu> wrote:
> >
> > I 100% agree with you on this.  If we can update binutils to the
> > latest and greatest, I believe powerpc64 would be able to work with
> > clang.  I've backported several patches, with IBM's permission, to
> > binutils for handling new relocations, etc.  However, not all patches
> > are straight forward, and currently we're missing something, which is
> > causing odd segfaults in ld(1), when linking as(1).  No other binary,
> > only as(1).  I've tried looking through it, but the binutils code is a
> > mess.  I'm sure the bug that's getting hit was fixed with newer
> > binutils, but have had a very hard time trying to test with it.
>
> We have support in the tree to use an external binutils automatically
> - we use this on arm64, which is completely unsupported by the in-tree
> binutils. External binutils is enabled by setting
> CROSS_BINUTILS_PREFIX=/usr/local/${TARGET_ARCH}-freebsd/bin/
>
> This happens automatically if the target specifies BINUTILS_BOOTSTRAP
> in BROKEN_OPTIONS -- for example, arm64 sets
> BROKEN_OPTIONS+=BINUTILS BINUTILS_BOOTSTRAP GCC GCC_BOOTSTRAP GDB
>
> I'd suggest that the first step in any of these discussions is to use
> this to test building with the binutils port. We know it won't work
> for mips today because upstream bintuils lacks FreeBSD/mips support.
> It may work for other targets though. Even if it doesn't the same work
> needs to be done regardless of whether the target uses an up-to-date
> binutils from ports or from the src tree.


Speaking of CROSS_BINUTILS_PREFIX, we need to unify CROSS*PREFIX stuff
with the CROSS_TOOLCHAIN stuff. Two different ways to specify thing.

Warner