svn commit: r264042 - in head: include lib/libc/gen lib/libc/include lib/libc/stdlib

[David Chisnall]

On 4 Apr 2014, at 13:44, Jordan Hubbard <jkh at ixsystems.com> wrote:

> On Apr 4, 2014, at 5:33 PM, David Chisnall <theraven at FreeBSD.org> wrote:
> 
>> The slight problem, however, is that we would still like to be able to build the base system with a more or less standard C compiler.  Blocks are in clang and are slowly making their way into commercial compilers, but the only two versions of gcc that support them are the ones shipped by Apple and FreeBSD.  
> 
> Huh.  Can I ask what specific need is driving that?  As you point out, you’ve got clang and you’ve also got the blocks support from Apple gcc back-ported, so that covers all the architectures you could possibly want to generate code for.  Wanting to hold base to some retro K&R standard for its own sake seems… weird… so I must be missing some part of the need statement, hence my question?

There are two requirements:

We'd like to kill off gcc 4.2.1 in base, because it doesn't support C11 or C++11. The lack of C++11 support is a problem because it means gcc architectures can't build libc++, so they need to use an old libstdc++ to build C++ things in the base system (which also means that these things can't take advantage of C++11, which cleans up the language a huge amount).  The prerequisite for this is the availability of external toolchains for the non-clang platforms.  If we could build base with gcc47 from ports, that would be okay, because then we'd have a modern C/C++ compiler in the base system and a modern(ish - 4.8 / 4.9 would be better, but 4.7 is a reasonable baseline) C/C++ compiler in ports to drive an external toolchain.

For embedded uses, we'd also like to build FreeBSD with vendor's-ugly-hacked-up-gcc-of-the-week.  This is less of an issue now for ARM, but MIPS vendors still hack up gcc in such a way that there's no way that they can get their changes upstreamed and then ship the result with their chips.

David