Re: [9fans] Compiling ken-cc on Linux

[arnold@skeeve.com]

> I know nothing about compilers, but actually gcc and clang dimension and
> complexity is astonishing.
> I've always thought that this is due to their desire to compile many
> different language optimized for many different OS and architectures on
> many different OS and architecture.

That is a very large part of the reason. People also have used GCC
(and I guess clang/llvm) as research vehicles, and such bits and pieces
get included even if not stricly necessary. Also note that C++ is a
hugely complicated langauge, and getting all the standards stuff right
for it (and even for C) takes a lot of work.  But you summed it up:

	* Multiple languages (front ends)
	* Multiple architectures (code generators / backends)
	* Optimized - a huge part of GCC is different kinds of optimizers

> Alternative compilers, like tcc, only build C on very few architectures /
> os with almost no optimization: they are much smaller, but still not
> standard compliant.
>
> How can it be?

In the case of TCC, there is no real guiding hand. People do what they
feel like, or as they need it.  Also, the original code base leaves a
lot to be desired from a software design / engineering standpoint.
(Function names consisting of a single letter!)

TCC compiles really fast, and it's (finally) good enough that I can use
it for my personal development / testing, but I would not use it to
build a production binary, the code quality is much poorer. On Linux
you can't use it for debugging either - it doesn't generate the
debug info you need. :-(  For that, GCC and clang are the way to go.

I agree with the general sentiments - GLIBC and GCC are both bloated.
But for the day-to-day work that *I* do, they're livable.

My two cents,

Arnold