Date: Fri, 6 Oct 2017 09:20:10 +0200 From: Baptiste Daroussin <bapt@FreeBSD.org> To: John Baldwin <jhb@freebsd.org> Cc: freebsd-arch@freebsd.org, "freebsd-arch@freebsd.org" <arch@freebsd.org> Subject: Re: Making C++11 a hard requirement for FreeBSD Message-ID: <20171006072010.ygq3k5ygwxykk4nb@ivaldir.net> In-Reply-To: <2116882.XEKuxOb729@ralph.baldwin.cx> References: <CANCZdfq5=KRp4NYKsc15gyS9C7CxrBFxcKQLPwnb_0oPb15vJw@mail.gmail.com> <2116882.XEKuxOb729@ralph.baldwin.cx>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --] 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 [-- Attachment #2 --] -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEgOTj3suS2urGXVU3Y4mL3PG3PloFAlnXLqcACgkQY4mL3PG3 PlrvUw//b+q++HQ/9nxMifoWutZk00Z42OThSJwiKbg4yAkmVz27OBgqCsUlOLZP SubeiDoMgkACOsZcB0j0yS/uF/NuUH/t4bAyHokmXF1u+CIB/CDZcq1WI0QkaUce nDYFPT42lMugCTdFbzFYT0H2XlBZt6+U9pr56eRVMdGSJHs44lVg1rY1ZHho6Gx/ 1Jb3q8Jt+sSJiu2VsAwDL7hQHa8ViBa4NuMqNl9U1e0lQYJTryQGuLf1VCl4tdnD 8BvzyGJFDJfgMLTk8BM11+mtyhOCgWXlpccjHASUgJgDrIXVpUc4svPluUD8K12d Q/BiWROAjfnDC/ZRp3C9FAqzYK9dMRRhPn8VC8Ufx/W5KJE4Hr5XphCDpVMDO3Ac CuDUgpSsHTjsCUUeHqshqD33/jaVu1wszka7m1QSVMTX7bfp2dgqcsOx/3pwHGFO tAuQrauxI1irsuNrJT1EhpWMXtKksL4hmXrcI/kAetVLhmhmrtpneGg5fM515BCL +dAllB8AoaT9GcYdpunVA7QWloKxOV3BwXSXjc8zgMqD2XxZe0GNAkWws6Pli9KQ SbaTG5tIwfc7aGGvwXieJW8DuNOcd1EByOEaxIaAK7lFwmqiE9BV2kjLpoY+JovE Fu/zItcMJFOuVRK2LKy713kbC3CbNyo2sk22zDmPXNu2whl4phg= =M5s0 -----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20171006072010.ygq3k5ygwxykk4nb>