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>