Re: GCC withdraw

On Thursday, August 29, 2013 1:02:06 pm David Chisnall wrote:
> On 29 Aug 2013, at 15:57, John Baldwin <jhb_at_freebsd.org> wrote:
> To summarise the current issues:
> 
> Our libstdc++ is ancient.  It supports C++98 well, it kind-of supports 
C++03.  It doesn't support C++11 at all and never will, nor does it support 
C++14.  An increasing number of ports are depending on C++11, because it 
provides much cleaner syntax than C++98 and so these are being forced to 
depend on gcc46 or gcc47 to build.  Unfortunately, libstdc++ in ports is not 
ABI compatible with the libstdc++ that we ship, which causes library ABI 
versions.  This problem will only get worse over the coming years.  An 
increasing number of these ports do build with libc++ (since it's the only 
option on OS X / iOS - most do already and most of the fixes needed are just 
adding some inclusions since libc++ doesn't leak C headers as much as 
libstdc++), so defaulting to libc++ will reduce these problems over time.  

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.

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

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.

> Maintaining out gcc is also not a zero-effort operation.  Even though it is 
not the default compiler for amd64 or i386, we still have to add support for 
new instructions to them, even if we only want to use them in machine-
dependent code on these architecture.  

The new instructions (and I've added some) go into binutils, not gcc per se.
Even the ARM ABI changes only touched Makefiles and one config header in
contrib/gcc, not actual code changes.  The code changes in contrib/gcc to
add more AMD instrinics were done because someone felt like doing it, not
because it was a requirement or blocking issue for someone.

> When we enable LLDB during the 10.x timeframe (emaste has been working hard, 
but it's probably not quite ready for 10.0), it will have to link against both 
LLVM libraries and libc++ (as it uses C++11 and doesn't work with our libc++).  
This is a minor issue, as the only requirement here is that we switch to 
linking LLVM against libc++ instead of libstdc++, but it is an example of one 
more piece of code that won't build with our gcc that is in the base system 
(not yet enabled by default).  Clang 3.4 will not build with our gcc either 
(which will cause some bootstrapping problems that we'll have to address for 
people going from 9.x to 10.1, but the clang 3.3 in 9.2 should be useable as 
long as we tweak the build system to use clang and not cc for the bootstrap 
build).

Eh, it sounds like if you have to force them to use clang for 9.x 
bootstrapping that also solves your problem in 10, so it's the same amount of 
work either way.

> 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. :)
 
> I have not heard any compelling arguments for keeping gcc and libstdc++ as 
part of the default install on x86, and I have listed a number of reasons why 
doing so creates extra work for people who maintain the toolchain and who work 
on ports.  I intend to commit the change to remove both from the default build 
and make libc++ the default STL for clang++ as soon as I get an okay from 
bapt.  

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.

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.

-- 
John Baldwin