Date: Tue, 10 Oct 2017 07:36:25 -0700 From: Nathan Whitehorn <nwhitehorn@freebsd.org> To: freebsd-arch@freebsd.org Subject: Re: Making C++11 a hard requirement for FreeBSD Message-ID: <7962d62e-3452-6eae-3816-3eca24fa4177@freebsd.org> In-Reply-To: <CANCZdfq7CcxXafc0r8WxS7o=qoH_xe0ePMNOgmegM4nEaXTqbw@mail.gmail.com> References: <CANCZdfq5=KRp4NYKsc15gyS9C7CxrBFxcKQLPwnb_0oPb15vJw@mail.gmail.com> <2116882.XEKuxOb729@ralph.baldwin.cx> <20171006072010.ygq3k5ygwxykk4nb@ivaldir.net> <e1b1b84a-9f6f-d0d7-7e26-b3ef3cc35698@freebsd.org> <CANCZdfoTJG6=d9xtyiNJ8sTdsnm_SfHaMhPbqgALv75dKgb8Kg@mail.gmail.com> <ef8f368d-7e21-a5dd-5351-9cb6cc020798@freebsd.org> <CANCZdfrqoHh2_knYrmNZF5d=VFt5csuFu%2BkT5XpKKnH%2B0-Xbig@mail.gmail.com> <577d3900-76f2-2c52-8ada-b8fb1fe881be@freebsd.org> <CANCZdfq7CcxXafc0r8WxS7o=qoH_xe0ePMNOgmegM4nEaXTqbw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 10/09/17 22:56, Warner Losh wrote: [...] >> "Bootable" is not the same as "usable" here. External toolchain powerpc64 >> *boots* fine -- and has for years -- but there isn't much you can actual >> *do* with the system except admire dmesg without the ability to install >> ports. > > Right, and at least some of the issues with powerpc64 are non-technical. If > you have binary packages, none of the things that you point out matter. > There's an external compiler that can be installed for cross building a > system, or you have a running system that you were able to build, so > necessarily have a compiler for further bootstrapping. I think they are *all* non-technical. We just need to have some official, blessed place to get that package from. Cross-building src/ is quite a lot easier than cross-building packages, and people do generally install some of our platforms (PPC, SPARC, etc.) from install media, so it would need to be there. > But doesn't clang work well enough for this on powerpc? If not, then > wouldn't we be in the same position with or without external toolchains? No. GCC works great, however, 4.2 and higher. > Let's focus on #1, the largest if not the only major problem. If I build, >>> say, a ppc64 system with an external toolchain right now, it boots and >>> runs >>> fine. But the system is completely unusable since: >>> - There are no binary packages built for PPC64, because of project policy >>> 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 specific >>> wrinkle for powerpc64 it seems. >>> >> How would I do that? We can't run these natively, because the system ships >> without a compiler. And we can't cross-compile, because the ports tree does >> not support that. > > Fair point about ports not supporting cross compile. I thought it > supported, though setting CC. If you can set CC, you can natively build the > packages. If not, then we should fix that. Most ports, however, just > require 'cc' to be in the path and don't much care if it is /usr/bin/cc or > /usr/local/bin/cc. Not generally. A few very specific packages work this way, but not all. You also need to bootstrap pkg somehow, which is itself a port, and binutils, and a few other things. It's almost certainly not a significant technical problem. > - You cannot cross-compile packages for PPC64, because of limitations in >>> QEMU >>> >>> >>> Then we should fix those, like we did for arm and MIPS. >>> >> That's a tremendous amount of work on a non-FreeBSD codebase. Are we now >> going to require QEMU patches from platform maintainers? > > Require? No. But other platform maintainers have fixed qemu when it was > broken for arm and mips. Sometimes Sean Bruno fixed it, other times he got > help from the port maintainer. But he really wanted packages. Yes, and that turned out to be incredibly complicated for PPC. I think there had been more heavy lifting ahead of time on Linux for ARM and MIPS, which made it easier. > - There is no compiler installed in the base system, so you cannot install >>> any software from source code >>> >>> >>> You can install it as a package. >>> >> Where do you get the package > > Well, if you have a native system, you needed one to build the system. Or maybe you downloaded the install media? All I want is for the install media to have a compiler on them or a way to get one. > Cross building is more tricky, I'll grant. A carefully curated set of > natively built compilers would suffice. > > >> - You cannot build the compiler from source, because you don't have one to >>> bootstrap from and can't get one pre-built because of the no-packages >>> problem. >>> >>> >>> If you fix the other problems, this is solved. >>> >> Yes, absolutely. But how do we solve the others? >> >> We can't ship systems like this -- how is anyone expected to be able to use >>> them? >>> >>> >>> Most systems don't build software, so there are plenty of uses. >>> >> I think all systems *install* software. If we don't have packages, then it >> has to be buildable from source and we need a compiler. We just can't close >> *both* paths. > > And the paths to get packages are solvable problems. They *should* be. There has been a policy brick wall on this for the last five years, which is why we *still* don't have any of this. > >> These are easy to fix -- for example, here are three possibilities -- but >>> solutions been held up for *years* by project policy: >>> 1. Allow Tier-2 packages to be built on native hardware without as much >>> centralized control, letting pkg install of the toolchain work. This fixes >>> ppc64, but maybe not embedded systems. >>> >>> >>> If we can't build in QEMU then sure. It doesn't matter where the binaries >>> come from, so long as they work. >>> >> Yes, agreed. This has not been project policy thus far, however. > > Policy changes all the time. As pointed out in other email, though, it's > more complicated and at least partially political. Yes. But this one, now, needs to be solved. If we can get a commitment from core@ to allow at least one of the options I outlined above by the deadline, I will be ecstatic. I do not think we can move forward otherwise. [...] >>> timeline, but wanting 100% full integration from external toolchain with >>> full packages isn't a gating factor here. >>> >> Absolutely! I don't want to make the perfect the enemy of the good, >> especially when the good is finally freeing ourselves from GCC 4.2. But we >> have been blocked for years by the fact that we have not been able, as a >> result of basically purely policy issues, to find a way to bootstrap a GCC >> 4.2-less system so that ports can be installed. And, as much as I like >> running fortune, I think not being able to install 3rd-party software is a >> blocker. > > Policy can be changed. > > Besides, I thought powerpc64 just worked with clang... It does not. It has been 90% of the way there for 6 years, but still is not there. >> Unfortunately, no. There are a wide variety of subtle issues. You can boot >> a kernel built with -O0, but higher optimization levels or userland code >> (especially C++) break. >> > C++ isn't needed to boostrap gcc. No, but it is needed to build clang, which it can't currently do. You also can't build a working kernel or libc. I haven't tried to build GCC with it lately, but the last time I tried, that also didn't work. > > >> Warner >>> Also, are there any directions for how to build a toolchain from the base >>> >>>> ports? I haven't been able to figure it out -- the README starts with >>>> "pkg >>>> install", but that doesn't get me very far on platforms without binary >>>> packages, which are the ones this is meant to target. >>>> >>> External toolchains are by definition external. Not part of the tree nor >>> integrated into the tree. How you get them depends on the external >>> toolchain and is unspecified. You get a lower level of integration than >>> you >>> do with in-tree toolchains, not the same level with reach-overs into some >>> external repo. >>> >>> >>> I think you missed the point. I was asking how to build the port to test >>> it >>> -- it doesn't build at present and I can't figure out how to make an >>> external toolchain via the "base" ports (the other toolchains in ports >>> work >>> fine). >>> -Nathan >>> >>> Warner >>> > I guess I'm looking for an actionable set of blockers with a timetable for > resolution. These all sound a lot like inconvenient problems stemming from > some bad choices of project controlled equipment. External toolchains could > be supplied by third parties as packages. That would solve much of the > bootstrapping problem. Some time spent fixing the bugs in qemu that keep it > from being a viable option would also open up a flood of packages (we have > good infrastructure for creating mips and arm packages today I'm told would > be relatively easy to expand to new architectures). > > However, absent a clear plan, as well as resourced dedicated to realize it, > I'm not sure that we should block things further based strictly on a list > of things that are broken. If there's a plan to fix, I'm willing to defer > to give that plan a chance to happen. In the absence of a specific plan > with timelines, I'm reluctant to indefinitely delay the negotiated plan for > 12 which has taken years to pull together. Otherwise, is 3 more months > enough? Is 6? are 12? Do we wait for FreeBSD 13? > 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). 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. 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) I am quite happy to do the technical work personally to enable one or all of these, but at present cannot do so because project policy prevents it and has done for a very, very long time. -Nathan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?7962d62e-3452-6eae-3816-3eca24fa4177>