From owner-freebsd-arch@freebsd.org Mon Nov 16 01:18:11 2015 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BCBF0A2F339; Mon, 16 Nov 2015 01:18:11 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from c.mail.sonic.net (c.mail.sonic.net [64.142.111.80]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id A0B371351; Mon, 16 Nov 2015 01:18:11 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from zeppelin.tachypleus.net (75-101-50-44.static.sonic.net [75.101.50.44]) (authenticated bits=0) by c.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id tAG1HeFC025825 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 15 Nov 2015 17:17:41 -0800 Subject: Re: Sparc64 doesn't care about you, and you shouldn't care about Sparc64 To: Justin Hibbits , Marius Strobl References: <563A5893.1030607@freebsd.org> <2AAC0EF3-528B-476F-BA9C-CDC3004465D0@bsdimp.com> <20151108155501.GA1901@alchemy.franken.de> Cc: sbruno@freebsd.org, freebsd-arch , sparc64@freebsd.org From: Nathan Whitehorn Message-ID: <56492EB4.1080307@freebsd.org> Date: Sun, 15 Nov 2015 17:17:40 -0800 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Sonic-CAuth: UmFuZG9tSVaXlyTcvSKUeK34kIATMPzVvr98eH+yLwlejlQgMjhOLvxzkTIy0JViFEX1hqRNy496m8IzL441MCSdjXF/ybgeYPyRrGanO50= X-Sonic-ID: C;2Imc1P+L5RGCOL0U9jFv0A== M;fEz51P+L5RGCOL0U9jFv0A== X-Spam-Flag: No X-Sonic-Spam-Details: 0.0/5.0 by cerberusd X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Nov 2015 01:18:11 -0000 On 11/08/15 12:46, Justin Hibbits wrote: > On 11/8/15, Marius Strobl wrote: > >> 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. >> > > > 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