Date: Fri, 30 Aug 2013 08:33:21 +0100 From: David Chisnall <theraven@FreeBSD.org> To: John Baldwin <jhb@FreeBSD.org> Cc: "Sam Fourman Jr." <sfourman@gmail.com>, toolchain@FreeBSD.org, "freebsd-current@freebsd.org CURRENT" <freebsd-current@FreeBSD.org>, Boris Samorodov <bsam@passap.ru>, FreeBSD Current <current@FreeBSD.org> Subject: Re: GCC withdraw Message-ID: <A981C965-D625-458B-B0AB-171C983AEA42@FreeBSD.org> In-Reply-To: <201308291344.25562.jhb@freebsd.org> References: <20130822200902.GG94127@funkthat.com> <201308291057.43027.jhb@freebsd.org> <8F836479-BC3A-4679-A7AA-3BCDD34AE6C5@FreeBSD.org> <201308291344.25562.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 29 Aug 2013, at 18:44, John Baldwin <jhb@freebsd.org> wrote: > How does removing GCC from base change this? I already deal with = having > 3 different GCC versions at work by building them from ports and = building > things with the right rpath, etc. so I am familiar with this, and = having > GCC in the base doesn't make that problem any worse. In fact, I'd = argue > that this is an argument for not shipping an STL in the base system at = all > (though I'd be loathe to do that) if it is an argument for disabling = GCC. It means that you don't need to patch configure scripts to tell them to = ignore gcc even if they find it. Please talk to port maintainers about = the amount of effort that they're being forced to put into this. = They'll still have to keep doing this until 9.x is EOL'd, but it would = be nice if they could then stop, rather than having to wait for 10.x to = also be EOL'd. >> Maintaining our libstdc++ is not a zero-effort operation. We have to = modify=20 > it whenever libc gains new features (e.g. POSIX2008 locales, new libm=20= > functions) and this requires developer time tracking down the new bugs=20= > (because the static configuration files no longer match the included = headers)=20 > and fixing them. >=20 > Strictly speaking you do not have to modify it in all cases. The = recent=20 > change to make it work with log10 does not appear to have been a = requirement=20 > to fix anything (at least judging from the log message). There does = seem to=20 > have been about 10 changes to libstdc++ in the past year, though a few = were=20 > 2-3 line changes in config.h which isn't but so earth-shattering. And each libc change that exposes anything that is used by libstdc++ = goes through the same cycle: - Commit - Wait for bug reports - Spend a few hours trying to work out why C++ programs are failing to = run or compile in odd ways - Commit a libstdc++ fix And, once again, the people who are advocating for gcc to remain in the = default install are not the ones doing this work. > Also, unless you plan on desupporting all non-x86 platforms, you = _still_ > have to do all this work while those platforms require GCC anyway. = Just > turning off GCC on x86 doesn't change this problem one iota. And that = point > is actually relevant to many of the other concerns you raised. It's = not at > all clear what disabling GCC on x86 will buy you unless you are = intending on > short-changing support for GCC on non-x86. It gives us a much cleaner deprecation strategy. Ports on tier-2 are = best effort. We don't need to be quite as careful to ensure that they = build with the base system compiler on tier-2 architectures. We don't = make as strong guarantees about compatibility on tier-2 architectures, = so removing gcc from their build at some point over the next five years = is fine, but this is not the case for tier 1 architectures, where we can = be reasonably expected to support anything that is in the base system = for the next five years. =20 If we remove it from the default install now, users don't expect it to = keep working for the lifetime of the 10.x branch. If we leave it in, = then they do. If tier-2 architectures are still using it for 10.0, = that's fine, because users of tier-2 architectures don't expect = everything to remain stable over the span of a release. =20 ARM is technically Tier-2, but for the purpose of this I'm including = modern ARM platforms (i.e. things like the Efika and Raspberry Pi, where = we hope to get re@-supported images soon - by 10.1 if not by 10.0), but = ARM EABI Hard-Float (the platform in question) is already supported by = clang and so has the same level of support as x86. =20 So let's be absolutely clear what we mean by non-x86: - Old ARM (ARMv4/ARMv5), most commonly used in microcontrollers which = don't have the power to run a full base system or arbitrary ports = anyway. =20 - MIPS, which is a few months of effort in LLVM to get completely = working. LLVM on MIPS is already self-hosting and I'm currently chasing = the remaining issues. We are planning on releasing an open source = MIPS64 implementation soon, and gcc will be the system compiler for the = first release, but we'll be switching to clang very soon for that - long = before 10.x goes EOL. MIPS has other serious issues (for example, gdb = doesn't work at all - it can't even find the memory regions that contain = the binary) and our ld is too old to support several of the GOT-related = optimisations required to build large programs, so gcc is the least of = its concerns, toolchain-wise. The MIPS binutils changes have not been = upstreamed, so this is somewhat problematic as we don't have any useable = toolchains for MIPS64, including gcc in base, for moderately-sized = applications. This should be addressed some time over the next 6-12 = months by switching MIPS over to LLVM / MCLinker. MIPS is perhaps the = most important one because the new owners of MIPS are investing in LLVM = quite heavily (they've been ramping up their LLVM development a lot over = the last year even before the purchase) and so it's important for us to = send a message to downstream FreeBSD/MIPS vendors that now is the time = to start thinking about switching toolchains. - PowerPC, which is a curiosity on old Apple hardware and is largely = used in embedded (mostly automotive?) applications beyond that. ANL = people are working hard on PowerPC 64 support for things like = BlueGene/Q, and PowerPC 32 is slowly coming along, although I think it's = missing a couple of things related to thread-local storage. For low-end = PowerPC32 embedded systems, most of the comments about ARMv4/5 apply. = For PowerPC64 - SPARC, which is effectively dead thanks to Oracle - Itanium, which is effectively dead thanks to Intel failing to learn = from their own mistakes By the way, I strongly resent the implication that I don't care about = non-x86 platforms, as I personally work on MIPS64 toolchain support and = have regular meetings with people at ARM about support there. >> Last but not quite least, people keep complaining about = ever-increasing=20 > build times and the size of the base system. Building a gcc and = libstdc++ by=20 > default every time, that we're telling people not to use, won't help = with=20 > that... >=20 > This is your worst argument as clang is known to take far longer than = GCC > to build. :) Not really. Clang + gcc takes longer to build than just clang. We can = also do a lot to fix clang build times by fixing our build systems to = properly expose the parallelism intrinsic in the build. I can build = LLVM+clang on my laptop in under 10 minutes with the upstream build = system, but doing it in the buildworld takes significantly longer. On a = 24-core system, it's under 3 minutes with the upstream build system, but = as long as on my laptop with ours. =20 > I posit that it only saves you work if you short-change non-x86 = platforms, > and that this will be harder to detect without gcc built on x86. I do = think > there is a decent chance that non-clang platforms will be more = aggressively > abandoned as a result of this change. By the end of the 10.x series, I expect non-clang platforms to be = SPARC64 and IA64. I don't think they need any help being abandoned - = their manufacturers seem to be facilitating this quite competently = without any assistance.=20 > Don't get me wrong, I don't love GCC per se, and on my laptop I've = hacked > the relevant ports so that everything is built with clang. I would = also > love to be able to build the base system with GCC 47 instead of 42, it = just > doesn't seem that we are there yet. The time to raise objections for this was when the plan was originally = raised over a year ago, or at any of the points when it's been discussed = in between. It is not after we're ready to flip the switch. David
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?A981C965-D625-458B-B0AB-171C983AEA42>