Tcc is actively maintained. Just check the mailing list or the git repo.
> On 20 Dec 2013, at 16:35, Paul Onyschuk <bl...@bojary.koba.pl> wrote: > > On Fri, 20 Dec 2013 13:49:43 +0100 > Sylvain BERTRAND <sylw...@legeek.net> wrote: > >> Is there any remaining good c++ compiler/runtime which can >> boostrap using a C compiler/minimal runtime? >> >> Since, it's near impossible to re-write/unroll all the >> "mandatory" c++ components in C quickly (harfbuzz, >> gecko/webkit...), what to do? Any suggestions? > > Not that I'm aware of, beside I'm not sure what benefits this would > bring? You're fine with C++ in one place, but not the other? > >> There is also the question of finding a new C99 optimizing >> compiler written properly in C of course. >> >> Anything else? > > This is valid question on other hand e.g. base OpenBSD is C++ free for > some time AFAIK (after the removal of groff). Idea of minimal set of > tools, capable of rebuilding itself is attractive. > > On one hand, you can use pretty old GCC and most of C codebase will > compile just fine (OpenBSD still uses patched GCC v4.2.1, which is more > than six years old). C is stable - you will more likely see changes in > standard C library, than compiler/language itself. GCC v4.7.x should > work just fine for some years to come. > > C++ is different kind of beast. More and more software requires C++11 > features and this means very recent version of compilers, especially > since C++ standard libraries are developed inside the same projects > (GCC/libstdc++, Clang/libc++). Sticking to GCC v4.7.x isn't an option > here as far I can tell. > > The last problem: C99-capable compiler isn't enough to get usable > system based on Linux. Clang which was designed as GCC drop-in > replacement chokes on Linux kernel (some patches are needed), because > it heavily uses GCC extensions and specific features (some > undocumented/undefined). > > PCC/TCC aren't actively developed, I'm not sure about the status of > firm/CParser. Still those alternative C compilers are just good > enough for specific programs and not larger set of packages. > > -- > Paul Onyschuk >
