Dear Michael, On Sun, Jul 12, 2026 at 02:35:47PM +0000, Michael Ackermann via Tinycc-devel wrote: > back on topic, i've pointed to the issue tinycc mob/HEAD is not directly > bootstrappable/compilable by pnut-cc or mes-cc anylonger and how this relates > to the trade-off between standards compliance and language features relied > upon. > Hence the route to spawn a fully capable C-compiler from macro-assembly > is at stake. I've too pointed to some solutions to this problem;
It looks like we have been talking past each other. That's unfortunate. You seem to emphasize the problems arising in the implementation of "bootstrapping from machine codes" (or from macro-assembly?). My primary question is then why/how such bootstrapping would be useful. Would you explain? The only argument I have seen so far from different information sources was to ensure that a toolchain binary is not tainted by a compiler backdoor. This "problem to solve" does not exist any more. I posted already the links to the explanations about the available solution, both conceptually and technically. Is there any other reason than to avoid the "trusting trust" compiler backdoors, to pursue the bootstrapping which you envision? I think that the answer to this question is relevant for the list, because there are apparently people here interested in compiler bootstrapping. > > you can repeat this process on virtually > > any Posix-like platform and verify that the result will be the same, > > reflecting only the sources used? > > See, this is _the_ major criteria if VSOBFS can be considered a full > system-bootstrap or not. Since it relies upon a _binary_ posix runtime > environment it is _not_ some fully source based solution either. Again, > this may not be relevant to yield "reproducible builds", but it's not a > complete system-bootstrap. What is wrong with Posix binaries? They are easily available and it does _not_ matter for the sanity of generated artifacts whether those binaries were auditable. > Anyway, I won't speak on behalf of live-bootstrap or where GNU guix is heading > in this regard. I've forked linux-tcc kernel including some grsecurity support > and updated drivers instead for that reason and backported a complete > musl-libc userspace. Which seems another difference, such a system can be > driven by tinycc-toolchain only 100% _without_ relying upon > gcc/binutils/llvm/clang anywhere. Personally and technically, I feel inspired when there is an open-source system without the toolchain bloat. Thanks for this work. > Otherwise, my bad mood isn't related to tccm or tinycc-devel at all, > but the trivial fact some hiring proceeding at a university in germany > was cancelled some month ago. They've only asked for more documents and > input without any contracting nor salary in return. No thanks. Hence i'm not > in the mood to proceed with anything. Michael, I am sorry to hear about your practical situation, can only wish you good luck. Regards /tccm _______________________________________________ Tinycc-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/tinycc-devel
