Making C++11 a hard requirement for FreeBSD

[Warner Losh]

On Tue, Oct 10, 2017 at 5:26 PM, John Baldwin <jhb at 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 at . 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.


> 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.

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? If we
look at why, we see that we don't have PowerPC hardware in the project that
can build packages. 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.

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.

Warner