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

Sean Bruno sbruno at
Sun Nov 8 21:43:56 UTC 2015

Hash: SHA512

On 11/08/15 12:46, Justin Hibbits wrote:
> On 11/8/15, Marius Strobl <marius at> wrote: 
> <snip>
>> As for getting forward, the FreeBSD Software License Policy 
>> ( 
>> 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.
> - Justin __________

- From IRC earlier, we discussed whether or not the ports for gcc and
binutils for various architectures work.  Does the binutils and gcc
port for sparc64 work (or powerpc)?

We know there are issues with MIPS binutils at this time (at least for

Version: GnuPG v2


More information about the freebsd-sparc64 mailing list