<oriansj>stikonas: well I was thinking of making that part of test1000; as the M2-Planet bootstrapped M2-Mesoplanet should be identicial to the M2-Mesoplanet self-hosted version. <stikonas>hmm, yes, but that uses make, not kaem, doesn't it? <stikonas>or were you thinking of using kaem for that <oriansj>#include might work best outside of cc_macro.c with some changes to cc_reader.c and #include being found in the token stream should probably become a major error <fossy>stikonas: plantman tcc cannot link linux kernel <stikonas>oriansj: yeah, cc_reader.c might be best. Although there should be some guard against infinite recursion... <fossy>tinycc is unable to link the linux kernel binary <fossy>it is also unable to compile some parts of it <stikonas>and we compile very minimal kernel binary ***bandali is now known as mab
<t184256>The part where I had no libc yet was... an interesting learning experience =) <janneke>t184256: any bootstrapping effort is interesting, and what you did looks great ***ChanServ sets mode: -o janneke
<oriansj>t184256: no such thing as not hardcore enough here, every step in the right direction deserves praise. <t184256>Thanks. I'll move on to making a toy distro on top of it, but I'll be rooting for stage0 project to solve the question of "where to get the initial trusted tcc binary from" =) <t184256>oriansj: wait, so there's some magic thing I run already? that wasn't obvious from the pages I was reading <oriansj>t184256: there is no need for magic here <oriansj>but yes, you can go from the tiny bootstrap hex0 all the way to GCC without anyting except a POSIX kernel to run the kaem-optional-seed <t184256>oriansj: I haven't come across that stage0-posix repo before, I'll sure take a look <oriansj>just be sure to do git clone --recursive <oriansj>as M2-Planet, mescc-tools, mescc-tools-extra, bootstrap-seeds and M2libc are also separate repos <t184256>and yeah, preface your all wiki pages and readmes with "this thing works already, just run this and that" <oriansj>fair, we have been a bit bad at marketing to say the least <t184256>from the two hours I spend looking at stage0 docs when I was starting that I got an impression that it's almost there, but not quite <oriansj>t184256: well yes, the bare metal bootstrap without any kernel still needs work <oriansj>but mescc-tools and M2-Planet are the universal sync point for the bare-metal, DOS and POSIX roots <oriansj>we just need a POSIX M2-Planet can bootstrap for the bare metal to go the rest of the way <oriansj>one can even verify the M2-Planet bare-metal output identicially matches the M2-Planet POSIX output. <oriansj>everything in stage0 and stage0-posix is designed for cross verification; so every port on every architecture and on every platform (baremetal, POSIX, DOS, etc) will produce identical output <oriansj>So completing stage0-posix is all that was really needed for someone wanting to do a trusted bootstrap <stikonas>t184256: and definitely take a look at live-bootstrap, it does similar things as your bootstrap but goes even a bit further: bootstraps all autogenerated files like configure, bison files, etc... <stikonas>we haven't done python yet (fossy is working on that) <stikonas>we did a bit of marketing, there have been some links on hackernews <stikonas>t184256: although, right now full bootstrap is only x86... <oriansj>t184256: yeah our announcement of bootstrapping GCC from hex got a grand total of 2 on hacker news <stikonas>in particular going from mes-m2 to tcc does not work on anything else except x86, not even amd64 <stikonas>and ideally we would get rid of mes-m2 altogether and be able to build upstream mes <oriansj>which is what the current C preprocessor work is about <oriansj>expanding the possible paths to a shared root of trust <stikonas>well, current C preprocessor work would not be enough... <stikonas>but the more we can do here, the less patches mes would need <oriansj>such as adding more architectures into MesCC <oriansj>porting mescc-tools and M2-Planet to more architectures <oriansj>new stage0-posix seed paths to M2-Planet <stikonas>also might be good if M2libc can build mes directly <t184256>Is there some high-level map of what project takes what as an input, does what and outputs what? <stikonas>t184256: we have some a bit outdated graph <t184256>got one at repository granularity? =) <stikonas>stage0-posix pulls in dependencies as submodules <stikonas>so stuff like mescc-tools, mescc-tools-extra, M2-Planet, M2libc, bootstrap-seeds <stikonas>so at repository level it depends on those <stikonas>after that we have untar and ungz, so can switch to using tarballs <stikonas>but basically there is mes-m2 fork of mes that we can build with M2-Planet <stikonas>then you can either build upstream mes or go directly to old and patched tcc 0.9.26 <t184256>stage0-posix goes from hex0 to mescc&m2-planet, live-bootstrap takes it from there and goes to familiar userspace? <oriansj>short version is only one repo is needed: stage0-posix; everything after that can be just tarballs because untar and ungz are included in the output; just leverage the after.kaem hook <stikonas>live-bootstrap pulls in stage0-posix as submodule if you use it <stikonas>and yes, live-bootstrap leverages after.kaem hook in stage0-posix <t184256>OK, so, what I hear: read stage0-posix, then it shouldn't be far to tcc 0.9.26 <oriansj>t184256: the steps after stage0-posix are mes-m2, which runs MesCC, which can be used to build tcc <oriansj>as you could see at the absolute bottom of the build graph posted earlier. <stikonas>oriansj: I might have gotten macro functions to work now <stikonas>also we should deal better with // comments in M2-Mesoplanet... <stikonas>since we no longer require bootstrap mode once we have Mesoplanet 