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
--hxaughgijyfspz4y Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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 f= or > > doing so. > >=20 > > 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 beca= use > > this has become a frequent request (but if you have opinions, please fi= nd > > the thread in current@ about it). I don't know the timeline of their pl= ans > > to do this. > >=20 > > I'd like to take the rather vague plans we've had "before 12" and creat= e 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 construc= ts. > >=20 > > I'd like to propose we do this 12/31/17. Any architectures that can't m= eet > > this timeline will be disconnected from universe at that time and delet= ed > > 3/31/18. > >=20 > > 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. >=20 > In-tree clang 5.0 for MIPS mostly works (modulo some small patches). How= ever, > 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-cap= able. >=20 > The problem with external GCC is that you can cross-build a world + kernel > just fine and get a working system via CROSS_TOOLCHAIN=3Dfoo-gcc. Howeve= r, > 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 anyo= ne > has thought about how release builds will work either with only an extern= al > 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. >=20 > 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. >=20 > 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 oth= er > architecture not using llvm libunwind. (Fixing that is a much smaller li= ft > than fixing clang on sparc64 btw, and I've successfully used llvm libunwi= nd > on mips worlds that are fully compiled with external GCC.) >=20 > That said, I definitely support the goal of requiring C++11. I will happ= ily > start using it myself in some userland bits (truss for example could bene= fit > from std::unordered_map<>) once it is available across the board. >=20 > 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. >=20 I'm fine with that date. Best regards, Bapt --hxaughgijyfspz4y Content-Type: application/pgp-signature; name="signature.asc" -----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----- --hxaughgijyfspz4y--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20171006072010.ygq3k5ygwxykk4nb>