Spent part of my #RechageDay at #AMD looking at bootstrapping #TinyCC 0.9.26 from #GNUMes on #x86_64 architecture. And thanks to #Mes mantainer @janneke for his help debugging various issues. We can now build initial #tcc binary and it can even run some simple commands such as --help or -vv.

Unfortunately, we still hit some critical bugs when trying to use this tcc binary to rebuild itself but hopefully we are not far now.

#bootstrappable
#BootstrappableBuilds
#ReproducibleBuilds

The only thing needed to compile a #CMake project with #TinyCC is:

`set(CMAKE_C_COMPILER tcc)`

when the TCC executable is in the path.

It might not be the best #C compiler, but it can act as a static library to offer compiler services to a client program.
And that feature is really great and otherwise known only in bloated frameworks.

TinyC did teach me how space efficient compilers can be.
Amazing!

https://en.wikipedia.org/wiki/Tiny_C_Compiler

@timorl

I used to trust #GCC.

I spent a huge amount of my free time over the last 2 years to port it to my operating system (a Plan 9 fork).

In fact, Jehanne has been the first Plan 9 fork to run a modern GCC (9.2.0) and compile C++ programs correctly.

Then, with the removal of #RMS by the GCC Steering Committee, I realized they cannot be trusted: https://gcc.gnu.org/pipermail/gcc/2021-April/235285.html

Indeed they are discussing to leave #GNU in these days.

Now I'm exploring the alternatives.

So far, #TinyCC looks promising: https://bellard.org/tcc/

Other alternatives are listed here http://suckless.org/rocks/ but some requires either linker or assembler.

And while I obviously ported GNU binutils too, I prefer to avoid this toolchain since they are all showing they do not give a shit about free software, but about "#IBM, #Google, #Facebook, #ARM, or other big supporters" https://gcc.gnu.org/pipermail/gcc/2021-April/235367.html

A serious alternative could be the 9front compiler suite that I dismissed years ago because I was still naive (dumb).

Also, it's urgent to design better programming languages, and for "better" I mean simpler both for humans and for compilers/interpreters. So that all people will be able to read the software they use.

But the point remains: if it cannot be completely read and understood in at most a month by a single professional programmer, it's broken beyond repair and need to be replaced.

You know @ekaitz_zarraga?

I'm trying #TinyCC! 😉

I gave a look to all the compilers at http://suckless.org/rocks/ but apparently #tcc is the most mature and the only one completelly self-sufficient.

BUT.

I do not know.

What it I restart from #9front?
No ELF. No #POSIX. No... shit.

It took a huge amount of work to do all this in #Jehanne but... why going after so much complexity? Why not just restart from scratch?

Give a look at this:
https://gcc.gnu.org/pipermail/gcc/2021-April/235367.html

Relying on #GNU (and on US-based software) is becoming a huge hazard.

Or more precisely, it's just proving to be such hazard and we were to naive to realize before.

We need to rebuild everything from scratch, anything that cannot be completely rebuilt in a month must be rewitten.

So what's the point of compatibility?

#LWN: "Bootstrappable builds"
"#GNU #Mes is the combination of a #Scheme interpreter written in #C and a #C compiler written in #Scheme. The two parts are mutually self-hosting, so one can be built from the other (or from a separate binary #C compiler or #Scheme interpreter). This has been used to halve the size of #bootstrap binaries (or "seeds") required to create a version of the #GNU #Guix #distribution."
https://lwn.net/SubscriberLink/841797/6742a0742f6160ef/
#Debian #NixOS #Stage0 #Hex0 #TinyCC