IRC channel logs
2025-03-23.log
back to list of logs
<LaurentH>Hi, I was looking at the Full-Source Bootstrap dependency graph and noticed that the path from TCC to GCC-4.9.4 passes through GCC-2.95.3. I thought TCC-0.9.27 was compatible with version 4.9.4 so I'm wondering why that intermediate step is required <fossy>iirc, guix needs it because they use glibc as their C library (?) which mes isn't really capable of building <fossy>take that with a grain of salt though, not 100% sure <fossy>gcc 2.95 100% builds with mes libc though, so i assume that might be another reason why... <LaurentH>I see! By mes libc, you mean glibc-mesboot (2.2.5)? Or is mes providing its own libc? <fossy>meslibc is a quite primitive libc provided alongside mescc as a very early libc that we use early on <fossy>the newest you could go with tcc is GCC 4.7.x, as gcc 4.8 introduced C++ as a buildtime dependency <fossy>i believe guix's bootstrap goes tcc + mes libc -> gcc 2.95 + mes libc -> gcc 2.95 + glibc 2.2 <fossy>live-bootstrap goes tcc + mes libc -> tcc + musl -> gcc + musl <LaurentH>Thanks for the link, I've been trying to compile musl with a bootstrapped version of TCC-0.9.27 produced from my compiler, but it seems there are far more details than I anticipated <LaurentH>A C to shell compiler, the idea being to use the many POSIX shell implementations for diverse double compilation <fossy>wrt the diverse double compilation, what is that protecting from? a malicious shell? <fossy>ahh, i have seen this before actually, very nice :D <LaurentH>It's mostly so we can have 1 shell that's used for all platforms! <LaurentH>Yeah I searched the logs and found a few message about my project =D <daddy>one shell to rule them all, one shell to build them <fossy>LaurentH: when you say "with an executable version that is still human readable", is that because the compiled pnut compiler is sufficiently "transpiled" such that it is still human readable? <fossy>because it appears to me pnut is still written in C, but i see how this makes sense if the resulting pnut.sh is still human readable <LaurentH>Yup, we tried to make the shell code as close to the original C code as possible <fossy>ahh, and you have a custom libc-ish thing for this too <LaurentH>we have 2, one for the shell backend and one for the native backend. The one for the native backend is enough to compile TCC, but it's very minimal and I really don't want to implement everything that's required by TCC <fossy>native backend? compiling to binary? <LaurentH>It would take forever to compile tcc otherwise XD <fossy>oh wow, you don't cheat here like most people do, you actually generate elfs <LaurentH>We do cheat a little, and jam the everything in 1 section <fossy>so if i understand correctly, pnut.sh compiles TCC's source code to an ELF, or at least that's the goal? <LaurentH>So we really have 2 compilers, pnut-sh (with the shell backend) and pnut-exe (with the native backend, x86 32 and 64 bit at this time). pnut-sh compiles pnut-exe to a shell script, let's call it pnut-exe.sh. And then pnut-exe.sh can compile pnut-exe to obtain an executable version of pnut-exe (that's much faster). And then we use pnut-exe to <LaurentH>That last step I completed this week, and I now need to find how to connect with the rest of the bootstrapping path <fossy>i will say, pnut-sh.sh _is_ probably human readable, but it's not very nice to do so... <fossy>honestly, it's probably a bit better than tcc is though :P <fossy>i see how this is fairly viable, especially for dcc purposes :) <fossy>and as you say in your presentation, diversity of bootstrapping approaches is a good thing <fossy>i'm usually fairly skeptical of most approaches as they usually cheat in some way, but this one has had thought put into it :) <LaurentH>I should probably spend some time reducing the size of pnut-sh.sh... The initial goal was to have a minimal seed that could also be used for DDC but we're quite far from minimal now XD <LaurentH>Thanks for the help fossy! I'll try running the live-bootstrap tomorrow and see where I can use pnut <fossy>i'd recommend reading up to tcc 0.9.27 in parts.rst to get an idea of how it works up to the point where pnut would be injected <LaurentH>I had to make a few changes to TCC to remove a few unsupported constructs and work around bugs in pnut's preprocessor. I can push my local version of TCC if you want to try <LaurentH>tcc compiled by pnut and gcc produce the same .o file for fib and pnut-sh, but there's a small diff when recompiling tcc from difference in the libc I believe (the bytes are in the .data section in between literals) <matrix_bridge><Andrius Štikonas> how come lots of changes are whitespace in your patch? <LaurentH>Oops! That's because my editor trims trailing whitespace but pnut handles them without problem <matrix_bridge><cosinusoidally> LaurentH: thanks, I was able to build tcc-by-pnut . I did hit a "Unknown strtold" error when I then used that version of tcc to try and compile libtcc1.c . I assume that's just because it's still wip? <LaurentH>Yes, we're still exploring ways to bootstrap floats, so far we've just been patching things as we go <LaurentH>You may also get "Function or label is not defined" warnings, that's when a function is missing and pnut-exe had to create a small stub for it <stikonas>yeah, when bootstrapping tcc with mescc, floats are also patched out I think <matrix_bridge><cosinusoidally> I managed to get around the libtcc1.c issue by building an intermediate version of tcc that used a dummy implementation of __floatundixf (basically int __floatundixf() {puts("__fixunsxfdi not impl");}). I then linked using gcc. The resulting version of tcc was then able to build libtcc1.c . Obviously what I did was a bit of a hacky work around then then depends on glibc. <stikonas>I'm unsure whether it's worth extra complexity or not <stikonas>a bit annoyingly, we can't use any of the new M2-Planet features in M1-macro.c since we still build it with --bootstrap-mode... <stikonas>so all those maybe_bootstrap_error() prevents us from using it