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

[Steffen Nurpmeso <sdaoden@yandex.com>]

arnold@skeeve.com wrote:
 |> 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.

 |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 just started to use tcc(1) for faster recompilations during my
chaotic way of walking, and it was an a-ha just as was the
detection of jikes(1) compared to the Java-shipped compiler in,
say, 1999.  (And in fact that was the reason to start learning
C++, later C, and not continue with only Perl and Java.)

  ?2[sdaoden@wales ]$ time make CC=clang devel >/dev/null 2>&1
      0m55.37s real     0m29.44s user     0m27.24s system
  ?0[sdaoden@wales ]$ time make CC=gcc devel >/dev/null 2>&1
      0m50.04s real     0m26.13s user     0m24.92s system
  ?2[sdaoden@wales ]$ time make CC=tcc devel >/dev/null 2>&1
      0m17.90s real     0m7.29s user     0m12.07s system

But without reconfiguration in normal development it feels more
drastic than these lines suggest.  Of course, ship-out user code.
Plan9 users don't have those problems in their native
self-contained environment, also the UnixWare and native Sun cc's
are ok, but on *BSD and Linux you really don't have any more
options.  E.g., i just tried pcc(1), which could be one, on
a Linux box:

  Using C compiler $CC="pcc"
  /usr/include/stdc-predef.h:59: warning: __STDC_ISO_10646__ redefined (previously defined at "./___tmp12443.c" line -9)
  ld: cannot find crtbegin.o: No such file or directory
well we could but..
  ld: cannot find -lpcc
there is none!
  error: ld terminated with status 1
  ERROR: i cannot compile a "Hello world" via
     pcc -I/usr/lib/gcc/x86_64-unknown-linux-gnu/5.2.0/include/ -I/home/sdaoden/usr/include -I/usr/local/include -I/usr/include      -L/home/sdaoden/usr/lib -L/lib -L/usr/local/lib -L/usr/lib

That after some work already.  VoidLinux has a package, though,
i should try that.

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

Due to the large community and the commercial interest (remember
the billion dollar campaign of IBM over a decade ago) you have the
newest technologies in a usable state.  I.e., i've found a drastic
memory bug in Jörg Schilling's Bourne shell (likely developed only
on Solaris rooted) simply by compiling and starting it under
FreeBSD.  And i have found stack read violations simply by running
them under Linux?  I always had my own memory allocation stuff
with tracing and logging and canaries, but read violations are
hard to detect without real red zones.  And it's easy to simply
look into /proc/PID/ and see a lot of things at a glance via ls(1)
/ cat(1) that otherwise require special programs or things which
are real horror for me, like dtrace (no!).  Acid has it at least
in its name.  Never liked debug robots anyway.

But otherwise i always like going back to BSD, i guess just Plan9
people like to come back into the grown rather self-contained
environment.  You install the ISO and are ready to go, with
network and development.  I.e., i install a new FreeBSD and the
configuration files from 2002 still work.  That is valuable.
I think there is pcc for NetBSD, also.

--steffen