Date: Tue, 10 Oct 2017 18:16:39 +0000 From: Brooks Davis <brooks@freebsd.org> To: John Baldwin <jhb@freebsd.org> Cc: freebsd-arch@freebsd.org, Nathan Whitehorn <nwhitehorn@freebsd.org> Subject: Re: Making C++11 a hard requirement for FreeBSD Message-ID: <20171010181638.GD68389@spindle.one-eyed-alien.net> In-Reply-To: <1723616.qgAo6xlX2y@ralph.baldwin.cx> References: <CANCZdfq5=KRp4NYKsc15gyS9C7CxrBFxcKQLPwnb_0oPb15vJw@mail.gmail.com> <CANCZdfrqoHh2_knYrmNZF5d=VFt5csuFu%2BkT5XpKKnH%2B0-Xbig@mail.gmail.com> <577d3900-76f2-2c52-8ada-b8fb1fe881be@freebsd.org> <1723616.qgAo6xlX2y@ralph.baldwin.cx>
next in thread | previous in thread | raw e-mail | index | archive | help
--TYecfFk8j8mZq+dy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Oct 10, 2017 at 06:49:44AM -0700, John Baldwin wrote: > On Monday, October 09, 2017 09:57:04 PM Nathan Whitehorn wrote: > >=20 > > On 10/09/17 11:32, Warner Losh wrote: > > > On Oct 9, 2017 11:47 AM, "Nathan Whitehorn" <nwhitehorn@freebsd.org> = wrote: > > > > > > > > > > > > On 10/08/17 22:26, Warner Losh wrote: > > > > > > > > > > > > On Sun, Oct 8, 2017 at 11:01 PM, Nathan Whitehorn <nwhitehorn@freebsd= =2Eorg> > > > wrote: > > > > > >> > > >> On 10/06/17 00:20, Baptiste Daroussin wrote: > > >> > > >>> 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 dead= line > > >>>>> 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 ongo= ing > > >>>>> discussion in another forum, and isn't appropriate for this thread > > >>>>> because > > >>>>> this has become a frequent request (but if you have opinions, ple= ase > > >>>>> find > > >>>>> the thread in current@ about it). I don't know the timeline of th= eir > > >>>>> 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 su= pport > > >>>>> 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 c= an'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 powerp= c64 are > > >>>>> ready for this change and mips* would be ready for this change wi= th an > > >>>>> external clang toolchain. I'm unsure of riscv and sparc64, but su= spect > > >>>>> 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=3Dfoo-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 thi= nk > > >>>> 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) th= ey 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 sparc= 64 was > > >>> my > > >>> guinea pig and so yes it worked an booted just fine. > > >>> > > >> So far as I know, we never solved any of the infrastructural problems > > >> associated with this concept: > > >> 1. Providing built releases with a /usr/bin/cc > > >> 2. Coversioning base and in-ports toolchain, including ensuring comm= it > > >> atomicity between toolchains and libc > > >> 3. Adding a dependency on ports for src, including out-of-tree code = that > > >> has to be fetched from external servers > > >> 4. Getting make universe to do the right thing > > >> > > >> We really need to solve those. If we go the external toolchain route, > > >> which it is not clear to me is the best option, #2 and #1 are quite = complex > > >> problems. I think that, frankly, a deadline in two months to solve t= his set > > >> of political problems we have had for two years is probably crazy, b= ut > > >> maybe making the status quo unsustainable will finally force progres= s. > > >> > > > External toolchains have been in flight for 5 or more years now. It's= time > > > they land. Though the requirements for them have never included > > > cross-threading between /usr/src and /usr/ports like you suggest abov= e, and > > > those sorts of things won't be sorted by my deadlines (which are clos= er to > > > 3 months). Nor, imho, should they. > > > > > > > > > Well, sure. But the fact remains that we cannot build usable systems = with > > > external toolchains right now. Those are real problems that need to be > > > solved somehow. > > > > > > > > > Sure we can. I've built a bootable i386 system with gcc 6. It is a so= lved > > > problem. > >=20 > > "Bootable" is not the same as "usable" here. External toolchain=20 > > powerpc64 *boots* fine -- and has for years -- but there isn't much you= =20 > > can actual *do* with the system except admire dmesg without the ability= =20 > > to install ports. > >=20 > > > Let's focus on #1, the largest if not the only major problem. If I bu= ild, > > > say, a ppc64 system with an external toolchain right now, it boots an= d runs > > > fine. But the system is completely unusable since: > > > - There are no binary packages built for PPC64, because of project po= licy > > > preventing the use of native build systems > > > > > > > > > System is still usable w/o packages. People can still fire up custom > > > poudrier repos. We could also change project policy. This is is a spe= cific > > > wrinkle for powerpc64 it seems. > >=20 > > How would I do that? We can't run these natively, because the system=20 > > ships without a compiler. And we can't cross-compile, because the ports= =20 > > tree does not support that. >=20 > The base/ ports _do_ cross-compile. See /usr/ports/base/README. You hav= e to > build a world image using the external toolchain that can then be used as= a > --sysroot with the external toolchain to build binutils and gcc packages. > These packages should then be able to be installed. To be clear, you wou= ld > build a world on an amd64 host with the foo-xtoolchain-gcc toolchain, ins= tall > it to some 'rootfs' directory, then build the base/ packages on the same > amd64 host but the generated packages can be installed on the target via > pkg install. In particular, we could automate building of the base/ pack= ages > in the cluster and publish repositories that contain just binutils and gc= c. I think building and publishing mini-repositories of pkg and "the things required to cross build a release" is a must. We should include the repo along side the releasese in the FTP[0] hierarchy. It's fairly straightforward and we should do it. -- Brooks [0] Can we please stop using this ancient protocol before we are the last signficant project using it and it is blocked by every enterprise firewall. --TYecfFk8j8mZq+dy Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJZ3Q6GAAoJEKzQXbSebgfAB2IIAINfDEEsWdLGRfk0x4HzJBK9 mkxAfAwrqaeJLdbAAaOKIMtH/rbHJfLW0aIw70PUj42OqhVogxOhEmbB+XpLGv8E Hn5Malyr1zHlgBnSl74sel9MfVMGUduQ1LVLFkF8nrXPgChtHUSZtySe6tBWmzhA 3BY761z69xp04MPllJvtfeitYie/Q6QybTFmuoiLoanQWrCIrC8TQ9kIlk7SdQAX cqrTD6ym5Tmr+/5nsNunjwr/1q2e02KZaeMJhGDeH2mbLHtdHjWT0T6MmPjDCxgT xYFFE/G06LBsW4zWN/tx+dvcAuTZwXlN96Hu6zDfyA/SfZZp5UhNIs6RWgdi2cc= =vq9B -----END PGP SIGNATURE----- --TYecfFk8j8mZq+dy--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20171010181638.GD68389>