Making C++11 a hard requirement for FreeBSD

[Baptiste Daroussin]

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.

> 
> Also, if you svn rm contrib/gcc you will nuke all of our systems because we
> still use 'crtstuff.c' from there on all architectures for part of the C
> startup code.  emaste@ has looked at a replacement for that from NetBSD in
> the past but I'm not sure what state that is in currently.
> 
> Another concern is fully replacing the compiler support libraries (libgcc and
> friends).  Some of those also come from contrib/gcc.  For mips I have some
> patches in review upstream to add mips to LLVM's libunwind (which allows mips
> to use that for libgcc unwinding).  I think sparc64 might be the only other
> architecture not using llvm libunwind.  (Fixing that is a much smaller lift
> than fixing clang on sparc64 btw, and I've successfully used llvm libunwind
> on mips worlds that are fully compiled with external GCC.)
> 
> That said, I definitely support the goal of requiring C++11.  I will happily
> start using it myself in some userland bits (truss for example could benefit
> from std::unordered_map<>) once it is available across the board.
> 
> 12/31/17 might be a bit aggressive given the holidays at the end of the
> quarter, but we can start with that and revisit if need be.
> 
I'm fine with that date.

Best regards,
Bapt
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-arch/attachments/20171006/819cf68d/attachment.sig>