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

[Nathan Whitehorn]

On 11/08/15 12:46, Justin Hibbits wrote:
> On 11/8/15, Marius Strobl <marius at alchemy.franken.de> wrote:
> <snip>
>> As for getting forward, the FreeBSD Software License Policy
>> (https://www.freebsd.org/internal/software-license.html)
>> specifically allows for existing GPLv2 licensed software in
>> the FreeBSD source tree to be updated to GPLv3 licensed one.
>> The initial, longer draft of this policy posted by brooks@ to
>> developers@ even explicitly mentioned key technologies such
>> as toolchains of other licenses being allowed when no mature
>> BSD-licensed alternative exists. So I propose just that:
>> Let's upgrade binutils and GCC in base to recent versions.
>> Seriously. That way we 1) don't need to get external toolchain
>> support into shape, 2) don't need to solve the chicken-and-egg
>> problem of getting a toolchain onto a machine installed from
>> a distribution built with an external toolchain and 3) once
>> clang becomes mature on additional architectures, we have an
>> upgrade path. Don't get me wrong, I'm only proposing that
>> for !arm and !x86.
>> As a side note: A while back I talked to grehan@ and marcel@
>> regarding the immaturities of clang and - as expected -, a
>> GPL'ed toolchain just is no problem for either NetApp or
>> Juniper as the binaries they ship don't include the toolchain
>> itself. With the possible exception of the current incarnation
>> of SCO which apparently sells a FreeBSD-based OS likely having
>> a system compiler, for the same reason I can't think of why a
>> GPLv3 licensed toolchain would matter for any of the commercial
>> downstream consumers of FreeBSD. Thus, I really can't understand
>> all that aggression regarding making FreeBSD 11 clang-only.
>>
> <snip>
>
> 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.
>
> TL;DR, let's update binutils at the very least, and gcc if it makes
> sense.  We shouldn't be relying on external toolchain for some archs,
> and internal for others.  It completely snubs already second class
> citizens.  Just look at the various build failures we've had because
> to some people All The World is clang/x86.
>

This would be super valuable. It would restore the upgrade path to clang 
broken at 3.5, allow us to use modern ABIs, everything. Is this 
something that is actually politically/legal doable?
-Nathan