Re: GCC withdraw

On 29 Aug 2013, at 18:44, John Baldwin <jhb_at_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 
> it whenever libc gains new features (e.g. POSIX2008 locales, new libm 
> functions) and this requires developer time tracking down the new bugs 
> (because the static configuration files no longer match the included headers) 
> and fixing them.
> 
> Strictly speaking you do not have to modify it in all cases.  The recent 
> change to make it work with log10 does not appear to have been a requirement 
> to fix anything (at least judging from the log message).  There does seem to 
> have been about 10 changes to libstdc++ in the past year, though a few were 
> 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.  

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.  

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_at_-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.  

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.  

- 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 
> build times and the size of the base system.  Building a gcc and libstdc++ by 
> default every time, that we're telling people not to use, won't help with 
> that...
> 
> 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.  

> 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. 

> 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