Date: Thu, 29 Aug 2013 13:44:25 -0400 From: John Baldwin <jhb@freebsd.org> To: David Chisnall <theraven@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: <201308291344.25562.jhb@freebsd.org> In-Reply-To: <8F836479-BC3A-4679-A7AA-3BCDD34AE6C5@FreeBSD.org> References: <20130822200902.GG94127@funkthat.com> <201308291057.43027.jhb@freebsd.org> <8F836479-BC3A-4679-A7AA-3BCDD34AE6C5@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thursday, August 29, 2013 1:02:06 pm David Chisnall wrote: > On 29 Aug 2013, at 15:57, John Baldwin <jhb@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201308291344.25562.jhb>