Sparc64 doesn't care about you, and you shouldn't care about Sparc64
nwhitehorn at freebsd.org
Mon Nov 16 01:18:12 UTC 2015
On 11/08/15 12:46, Justin Hibbits wrote:
> On 11/8/15, Marius Strobl <marius at alchemy.franken.de> wrote:
>> 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.
> 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?
More information about the freebsd-sparc64