Date: Tue, 10 Oct 2017 20:02:30 -0700 From: Nathan Whitehorn <nwhitehorn@freebsd.org> To: Warner Losh <imp@bsdimp.com>, John Baldwin <jhb@freebsd.org> Cc: "freebsd-arch@freebsd.org" <freebsd-arch@freebsd.org> Subject: Re: Making C++11 a hard requirement for FreeBSD Message-ID: <4fe9be52-fbc6-4b74-c869-7225f7e2df5f@freebsd.org> In-Reply-To: <CANCZdfqq-s7Otp7G4tZn4HONfENt5Qtk-JGh1CgLeDvkjbfyaw@mail.gmail.com> References: <CANCZdfq5=KRp4NYKsc15gyS9C7CxrBFxcKQLPwnb_0oPb15vJw@mail.gmail.com> <CANCZdfq7CcxXafc0r8WxS7o=qoH_xe0ePMNOgmegM4nEaXTqbw@mail.gmail.com> <7962d62e-3452-6eae-3816-3eca24fa4177@freebsd.org> <1966623.eKrA7uLGIR@ralph.baldwin.cx> <CANCZdfqq-s7Otp7G4tZn4HONfENt5Qtk-JGh1CgLeDvkjbfyaw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 10/10/17 19:36, Warner Losh wrote: > > > On Tue, Oct 10, 2017 at 5:26 PM, John Baldwin <jhb@freebsd.org > <mailto:jhb@freebsd.org>> wrote: > > On Tuesday, October 10, 2017 07:36:25 AM Nathan Whitehorn wrote: > > I think we can fix the problem, which is severe, in a week if we > can get > > a commitment from core@ to allow at least one of the following > things: > > > > 1. Package sets (potentially only very minimal ones) uploaded > for tier-2 > > systems from machines not controlled and hosted by portmaster, but > > otherwise project-affiliated (like our PPC build systems). > > > You should take that up with core@. Individuals can provide these > packages, of course, but part of the project's providing packages is > ensuring that the packages have a clear provenance. That's tricky to > do on machines the project provides. > > > 2. The "base" ports built as part of the release/snapshot > process and > > either included on the media (better) or, at the least, > available on the > > official package repositories. > > > That's possible, but there's no release integration for external > toolchains. And for tier 2 platforms, there's no requirement to do so. > And nobody's stepped up to do this work. > > > 3. Allow inclusion of the compiler either in src or in another > > project-hosted repository connected to src (I realize this isn't > > external toolchain, but it does still allow us to remove GCC 4.2 > without > > making the system unusable) > > > This has its own issues. I'm not sure how this would play out. It > seems like a lot of work, and nobody's name is by it. > > There's also: > > 4. Fix QEMU's issues with powerpc user mode emulation and get slotted > into the same cluster we have building arm and soon mips packages. It > seems to me to be less work than #3 or even #2, and doesn't have the > clear provenance issues #1 has. We have good infrastructure here, > though some of it depends currently on setting up native binaries that > produce target output to improve the speed. That's not a requirement, > though, and 100% emulation is possible, but slow. Still, it beats the > alternative we have today: which is no way to produce anything the > project can release. This has been in progress for years and is very hard. #2 or #3 are super easy, except from an administrative standpoint, where, like #1, they have proved impossible. I am stepping up to do the work right now, and have for a long time, but the work is entirely administrative and has been blocked. > I would prefer 2) as I think that is most consistent with what > other folks > have been pushing towards. I would be fine if we just hosted them in > repositories so that 'pkg install' worked out of the box. At least > if we > start building them and publishing the repositories I think it is much > easier to do more testing of them. Eventually we may also want > them on > the install media along with the base system dists, but just > having them > regularly built and published would be a good first step. I would > propose > that we build the sysroot required using the foo-xtoolchain-gcc > toolchains. > > > If this can be cross built, then that's a good first step. We'd need > some way to produce those packages that the ports that do cross build > work on. The lack of native machines under project control, or of qemu > (either userland or full system) limit our options here. > > We don't yet produce any install images for MIPS. If we did I would > advocate that we start providing release snapshots built using > mips-xtoolchain-gcc (make CROSS_TOOLCHAIN=blah) and use the base > dist from > those releases as the sysroot to also build the base/ packages and > provide > those in a repository. > > I think that same approach could be perhaps more readily adopted for > powerpc. That is, cross-building releases using > powerpc-xtoolchain-gcc and > then using the resulting base dist as a sysroot to build the base/ > packages > and publishing both of those as our snapshots for current. > > > That's another path forward, but as you point out would require some > more integration work. We can build the raw images today, but the > snapshot integration to generate installable images aren't there. > > I suspect our release generation bits don't yet understand > CROSS_TOOLCHAIN > and probably will need some changes to handle that. > > > That would be nice, but integration into the release process never was > part of the discussion on external toolchains. It was envisioned for a > tier-2 or 3 architecture where release engineering or security officer > integration isn't guaranteed. Both powerpc and mips are tier 2 > platforms, which make it more of a challenge to use them. And yet, we *do* provide releases for them consistently. > > But I'm puzzled about something. We don't provide packages today, why > should that become a new requirement to remove gcc from the tree? Because we currently have users build from ports with the compiler included in the system. If we take that compiler away, we provide only the option to install a compiler from packages. If we also don't provide a compiler package, the system is a brick and we might as well remove the platform from the tree. > If we look at why, we see that we don't have PowerPC hardware in the > project that can build packages. We do have PowerPC hardware on which we can build packages, but we do not actually do that for a variety of largely administrative reasons that are out of scope for this thread. > We don't have an emulation alternative like we do for arm and mips to > fall back on. If the cross building works for a small number of > packages, we could create a pkg release repo for that. So long as we > have a complete chain of custody, there should be no barrier to doing > this, even if we don't release release images. This wouldn't be hard > to do, but someone needs to do the work and integrate into the tree > and src/release. If this is the plan, great. I'm happy to do whatever technical work is required for this to meet your end-of-year deadline so long as the project is actually willing to support this. > But all these things are stuff we could do. I'm happy to delay to give > people time to do them. However, I'd like to know who is doing the > stuff and on what timeframe. If someone can come up with that, then I > can push back the proposed timeline. I don't oppose any of this. I > think it's all great. I just oppose delaying for vague plans. It's not vague: If we have a commitment to cross-build the toolchain packages and upload them with releases, then we're all done here. If we don't have that, then removing GCC 4 makes all tier-2 platforms except ARM totally unusable. The two need to be coupled in the proposal. -Nathan > > Warner
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4fe9be52-fbc6-4b74-c869-7225f7e2df5f>