Date: Tue, 10 Oct 2017 13:27:23 -0600 From: Warner Losh <imp@bsdimp.com> To: Brooks Davis <brooks@freebsd.org> Cc: John Baldwin <jhb@freebsd.org>, Nathan Whitehorn <nwhitehorn@freebsd.org>, "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org> Subject: Re: Making C++11 a hard requirement for FreeBSD Message-ID: <CANCZdfrvLUH8EKT_wphuBkdtuwCx9pVYNVMRmVm%2BX82KRgtyQA@mail.gmail.com> In-Reply-To: <20171010181638.GD68389@spindle.one-eyed-alien.net> References: <CANCZdfq5=KRp4NYKsc15gyS9C7CxrBFxcKQLPwnb_0oPb15vJw@mail.gmail.com> <CANCZdfrqoHh2_knYrmNZF5d=VFt5csuFu%2BkT5XpKKnH%2B0-Xbig@mail.gmail.com> <577d3900-76f2-2c52-8ada-b8fb1fe881be@freebsd.org> <1723616.qgAo6xlX2y@ralph.baldwin.cx> <20171010181638.GD68389@spindle.one-eyed-alien.net>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Oct 10, 2017 at 12:16 PM, Brooks Davis <brooks@freebsd.org> wrote: > On Tue, Oct 10, 2017 at 06:49:44AM -0700, John Baldwin wrote: > > On Monday, October 09, 2017 09:57:04 PM Nathan Whitehorn wrote: > > > > > > On 10/09/17 11:32, Warner Losh wrote: > > > > On Oct 9, 2017 11:47 AM, "Nathan Whitehorn" <nwhitehorn@freebsd.org> > wrote: > > > > > > > > > > > > > > > > On 10/08/17 22:26, Warner Losh wrote: > > > > > > > > > > > > > > > > On Sun, Oct 8, 2017 at 11:01 PM, Nathan Whitehorn < > nwhitehorn@freebsd.org> > > > > wrote: > > > > > > > >> > > > >> On 10/06/17 00:20, Baptiste Daroussin wrote: > > > >> > > > >>> On Thu, Oct 05, 2017 at 11:47:57PM +0000, John Baldwin wrote: > > > >>> > > > >>>> On Thursday, October 05, 2017 04:28:44 PM Warner Losh wrote: > > > >>>> > > > >>>>> I'd like to start a conversation about the viability of making > C++11 a > > > >>>>> hard > > > >>>>> requirement for bootstrapping FreeBSD and setting a specific > deadline > > > >>>>> for > > > >>>>> doing so. > > > >>>>> > > > >>>>> This discussion is motivated by an ask from the jemalloc folks > to use a > > > >>>>> limited subset of C++11 inside of malloc in such a way that is C > safe > > > >>>>> (so > > > >>>>> the C programs wouldn't bloat with a C++ runtime). That's an > ongoing > > > >>>>> discussion in another forum, and isn't appropriate for this > thread > > > >>>>> because > > > >>>>> this has become a frequent request (but if you have opinions, > please > > > >>>>> find > > > >>>>> the thread in current@ about it). I don't know the timeline of > their > > > >>>>> plans > > > >>>>> to do this. > > > >>>>> > > > >>>>> I'd like to take the rather vague plans we've had "before 12" and > > > >>>>> create a > > > >>>>> timeline for removal of gcc 4.2 coupled with a requirement for > support > > > >>>>> in > > > >>>>> clang or a working external toolchain. This requirement would be > coupled > > > >>>>> with the requirement that the external toolchain support C++11 > > > >>>>> constructs. > > > >>>>> > > > >>>>> I'd like to propose we do this 12/31/17. Any architectures that > can't > > > >>>>> meet > > > >>>>> this timeline will be disconnected from universe at that time and > > > >>>>> deleted > > > >>>>> 3/31/18. > > > >>>>> > > > >>>>> It's my belief that i386, amd64, arm, aarch64, powerpc and > powerpc64 are > > > >>>>> ready for this change and mips* would be ready for this change > with an > > > >>>>> external clang toolchain. I'm unsure of riscv and sparc64, but > suspect > > > >>>>> that > > > >>>>> a newer version of gcc as an external toolchain could work. > > > >>>>> > > > >>>> In-tree clang 5.0 for MIPS mostly works (modulo some small > patches). > > > >>>> However, > > > >>>> it requires external ld.bfd. I know that there ld.lld can link a > working > > > >>>> mips64 world with some patches (notably the multigot patch). > mips works > > > >>>> fine > > > >>>> with external GCC. riscv is already using external GCC that is > > > >>>> C++11-capable. > > > >>>> > > > >>>> The problem with external GCC is that you can cross-build a world > + > > > >>>> kernel > > > >>>> just fine and get a working system via CROSS_TOOLCHAIN=foo-gcc. > However, > > > >>>> that system has no viable '/usr/bin/cc' once GCC 4.2 is removed. > bapt@ > > > >>>> started on ports to cross-build binutils and gcc packages via the > base/* > > > >>>> ports, but those are not yet finished / fully tested. I don't > think > > > >>>> anyone > > > >>>> has thought about how release builds will work either with only an > > > >>>> external > > > >>>> toolchain available. (I'm pretty sure sparc64 has booted fine > with > > > >>>> external GCC, it's just in the same boat as mips with regard to > > > >>>> /usr/bin/cc.) > > > >>>> > > > >>> Actually I did test those and they were working (tested in qemu) > they were > > > >>> working fine. I have given up working on them due to the lack of > > > >>> interested by > > > >>> the community (by interest I mean people really testing, working > on it, > > > >>> not just > > > >>> saying "hey nice sounds cool"). > > > >>> > > > >>> As for the boot when I initially worked on external toolchain > sparc64 was > > > >>> my > > > >>> guinea pig and so yes it worked an booted just fine. > > > >>> > > > >> So far as I know, we never solved any of the infrastructural > problems > > > >> associated with this concept: > > > >> 1. Providing built releases with a /usr/bin/cc > > > >> 2. Coversioning base and in-ports toolchain, including ensuring > commit > > > >> atomicity between toolchains and libc > > > >> 3. Adding a dependency on ports for src, including out-of-tree code > that > > > >> has to be fetched from external servers > > > >> 4. Getting make universe to do the right thing > > > >> > > > >> We really need to solve those. If we go the external toolchain > route, > > > >> which it is not clear to me is the best option, #2 and #1 are quite > complex > > > >> problems. I think that, frankly, a deadline in two months to solve > this set > > > >> of political problems we have had for two years is probably crazy, > but > > > >> maybe making the status quo unsustainable will finally force > progress. > > > >> > > > > External toolchains have been in flight for 5 or more years now. > It's time > > > > they land. Though the requirements for them have never included > > > > cross-threading between /usr/src and /usr/ports like you suggest > above, and > > > > those sorts of things won't be sorted by my deadlines (which are > closer to > > > > 3 months). Nor, imho, should they. > > > > > > > > > > > > Well, sure. But the fact remains that we cannot build usable systems > with > > > > external toolchains right now. Those are real problems that need to > be > > > > solved somehow. > > > > > > > > > > > > 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 actual *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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CANCZdfrvLUH8EKT_wphuBkdtuwCx9pVYNVMRmVm%2BX82KRgtyQA>