From owner-freebsd-arch@freebsd.org Tue Oct 10 22:30:32 2017 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 AC17EE3F00F for ; Tue, 10 Oct 2017 22:30:32 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from d.mail.sonic.net (d.mail.sonic.net [64.142.111.50]) (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 932B46F953; Tue, 10 Oct 2017 22:30:32 +0000 (UTC) (envelope-from nwhitehorn@freebsd.org) Received: from helicon.physics.ucla.edu (helicon.physics.ucla.edu [169.232.156.253]) (authenticated bits=0) by d.mail.sonic.net (8.15.1/8.15.1) with ESMTPSA id v9AMUStv011765 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Tue, 10 Oct 2017 15:30:29 -0700 Subject: Re: Making C++11 a hard requirement for FreeBSD To: Warner Losh , Brooks Davis Cc: John Baldwin , "freebsd-arch@freebsd.org" References: <577d3900-76f2-2c52-8ada-b8fb1fe881be@freebsd.org> <1723616.qgAo6xlX2y@ralph.baldwin.cx> <20171010181638.GD68389@spindle.one-eyed-alien.net> From: Nathan Whitehorn Message-ID: <347c5440-ec85-8912-6621-d9c057f58493@freebsd.org> Date: Tue, 10 Oct 2017 15:30:27 -0700 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Language: en-US X-Sonic-CAuth: UmFuZG9tSVYfVat1Ygleatpo2WoDIepyw0PasePoNqneCEurO/6g5jH0VtUlxYQNRopW+9nRrwixVSdpcvycrTKvFynBUzKKVWPXm7ZutFE= X-Sonic-ID: C;iEEengqu5xGvOYlQ3iMJ6w== M;0qKzngqu5xGvOYlQ3iMJ6w== X-Spam-Flag: No X-Sonic-Spam-Details: 0.0/5.0 by cerberusd Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Oct 2017 22:30:32 -0000 On 10/10/17 12:27, Warner Losh wrote: > > [...] > > > > > > > > > Sure we can. I've built a bootable i386 system with gcc 6. > It is a solved > > > > problem. > > > > > > "Bootable" is not the same as "usable" here. External toolchain > > > powerpc64 *boots* fine -- and has for years -- but there isn't > much you > > > can actually *do* with the system except admire dmesg without > the ability > > > to install ports. > > > > > > > Let's focus on #1, the largest if not the only major > problem. If I build, > > > > say, a ppc64 system with an external toolchain right now, it > boots and runs > > > > fine. But the system is completely unusable since: > > > > - There are no binary packages built for PPC64, because of > project policy > > > > preventing the use of native build systems > > > > > > > > > > > > System is still usable w/o packages. People can still fire > up custom > > > > poudrier repos. We could also change project policy. This is > is a specific > > > > wrinkle for powerpc64 it seems. > > > > > > How would I do that? We can't run these natively, because the > system > > > ships without a compiler. And we can't cross-compile, because > the ports > > > tree does not support that. > > > > The base/ ports _do_ cross-compile.  See > /usr/ports/base/README.  You have to > > build a world image using the external toolchain that can then > be used as a > > --sysroot with the external toolchain to build binutils and gcc > packages. > > These packages should then be able to be installed.  To be > clear, you would > > build a world on an amd64 host with the foo-xtoolchain-gcc > toolchain, install > > it to some 'rootfs' directory, then build the base/ packages on > the same > > amd64 host but the generated packages can be installed on the > target via > > pkg install.  In particular, we could automate building of the > base/ packages > > in the cluster and publish repositories that contain just > binutils and gcc. > > I think building and publishing mini-repositories of pkg and "the > things > required to cross build a release" is a must.  We should include the > repo along side the releasese in the FTP[0] hierarchy. It's fairly > straightforward and we should do it. > > -- Brooks > > [0] Can we please stop using this ancient protocol before we are the > last signficant project using it and it is blocked by every enterprise > firewall. > > > Given that PowerPC is a tier 2 architecture, I'm not sure that I'd > call it a MUST. It's nice to have, and really useful if we have it. > But Tier 2 is best effort to support, so it isn't a "must" in the > sense it is a hard blocker for the removal of gcc. > > However, if there's plans in flight to do this, I'll let the complete > (or timeout) before moving forward with any deorbiting. So long as > there's a concrete timeline of reasonable things, I'm happy to defer > to allow that to proceed. What I don't want to do is defer to some > vague plans by some unnamed individuals that might get around to it, > but we're blocked on that... > > Warner This problem applies to all architectures except ARM and x86 and removal of the compiler from the base system without doing something like this will make any installed system unusable. It should be a blocker. We have multiple volunteers to do the work, which, as Brooks notes, is super easy, but need a change in project policy, which has prevented the work in question from being done for many years. If you include that policy change as part of your proposal, I am very happy to support it. -Nathan