From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Fri, 27 Nov 2015 14:33:12 +0100 From: Steffen Nurpmeso To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Message-ID: <20151127133312.4nVVd3cC7%sdaoden@yandex.com> References: <877fl6ronj.fsf@rudra.copyninja.info> <835ECE9E-472C-448D-8125-67BBACB09752@gmail.com> <69275011-637E-4D0C-9E17-2F0CF1B93503@gmail.com> <201511270856.tAR8uBol016809@freefriends.org> In-Reply-To: <201511270856.tAR8uBol016809@freefriends.org> User-Agent: s-nail v14.8.5-176-g4c6d78d MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [9fans] Compiling ken-cc on Linux Topicbox-Message-UUID: 78df1dbc-ead9-11e9-9d60-3106f5b1d025 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=3Dclang devel >/dev/null 2>&1 0m55.37s real 0m29.44s user 0m27.24s system ?0[sdaoden@wales ]$ time make CC=3Dgcc devel >/dev/null 2>&1 0m50.04s real 0m26.13s user 0m24.92s system ?2[sdaoden@wales ]$ time make CC=3Dtcc 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=3D"pcc" /usr/include/stdc-predef.h:59: warning: __STDC_ISO_10646__ redefined (pre= viously 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/sda= oden/usr/include -I/usr/local/include -I/usr/include -L/home/sdaoden/u= sr/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=C3=B6rg 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