Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 15 Nov 2015 17:17:40 -0800
From:      Nathan Whitehorn <nwhitehorn@freebsd.org>
To:        Justin Hibbits <jrh29@alumni.cwru.edu>, Marius Strobl <marius@alchemy.franken.de>
Cc:        sbruno@freebsd.org, freebsd-arch <freebsd-arch@freebsd.org>, sparc64@freebsd.org
Subject:   Re: Sparc64 doesn't care about you, and you shouldn't care about Sparc64
Message-ID:  <56492EB4.1080307@freebsd.org>
In-Reply-To: <CAHSQbTDEUJ=R4BTAx%2BVF55Xb%2BmObhHLgM09%2Bxp-=uP8LbfeoUA@mail.gmail.com>
References:  <563A5893.1030607@freebsd.org> <2AAC0EF3-528B-476F-BA9C-CDC3004465D0@bsdimp.com> <20151108155501.GA1901@alchemy.franken.de> <CAHSQbTDEUJ=R4BTAx%2BVF55Xb%2BmObhHLgM09%2Bxp-=uP8LbfeoUA@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help


On 11/08/15 12:46, Justin Hibbits wrote:
> On 11/8/15, Marius Strobl <marius@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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?56492EB4.1080307>