<oriansj>but that can be worked around by not invoking blood-elf with the -g flag <vagrantc>oriansj: are you saying that mes.git/INSTALL is incorrect about the prerequisites? <stikonas>vagrantc: I saw that error (cell_symbol_record_type) an hour ago but probably due to different cause <stikonas>(I was building with kaem and globals.c was missing) <oriansj>vagrantc: yes it is clearly wrong as you don't need two different C compilers to build a single C program <oriansj>as if you notice next to M2-Planet it says optional <vagrantc>oriansj: well, it fails to build when i remove mescc-tools from the build-depends for the debian packaging <vagrantc>so, the way it is written, it is required somehow <oriansj>well yes, it needs mescc-tools to actually build anything <oriansj>so it needs mescc-tools to build anything (including itself) <vagrantc>probably the test suite will also need them <vagrantc>from my perspective, maybe there's some way to build it without, but ... it is clearly needed to build them using standard processes <oriansj>there is absolutely no way for mescc to successfully pass its tests without mescc-tools <stikonas>well, blood-elf, M1 and hex2 are needed for M2-Planet -> mes build <oriansj>mescc-tools is a hard dependency for both M2-Planet and mescc <oriansj>M2-Planet can kinda work around alternates but mescc-tools are hard-coded in mescc <oriansj>and the posted error message is a straight hex2 error <oriansj>in that folder where it failed I would do grep -R cell_symbol_record_type and you'll find exactly what .o file contains the issue we can then trace <stikonas>or maybe it's not necessary for mescc build <vagrantc>oh, there are also some .o files in the top-level directory that match ... but just as binaries <oriansj>looking at your paste the conclusion is mescc failed to include any file where the label :cell_symbol_record_type is defined <stikonas>fossy: I've updated my PR, do you want to re-review it or should I push it? <littlebobeep>oriansj: Can you explain a bit about what you were talking about a kernel built with M2-Planet? Would this be used for a bare metal bootstrap with stage0? <achaninja>Does anyone know why live-bootstrap builds tcc twice? <Hagfish>"First, we compile janneke’s fork of tcc 0.9.26 using mescc, containing 27 patches to make it operate well in the bootstrap environment and make it compilable using mescc." <Hagfish>i don't know if those patches could be ported forwards to 0.9.27 <achaninja>yeah I also dunno if 0.9.27 has something particularly important <Hagfish>oh, you're thinking the whole process could stick with .26? <Hagfish>yeah, i don't know if anything later in the chain requires something .27 specific <stikonas>achaninja: tcc is rebuild multiple times because original is either buggy or missing features <stikonas>mescc->tcc 0.9.26 step involves building tcc 6 times <stikonas>then after musl live-bootstrap rebuilds tcc twice (second rebuild is much less buggy) <stikonas>anyway, you can always remove some step and see what breaks <stikonas>amd we definitely need 0.9.27 in the chain <stikonas>neither gcc nor even musl (much earlier) can't be built with tcc 0.9.26 <littlebobeep>stikonas: wow that's complex... 6 recompilations of tcc? How do we determine these are all reproducable? <stikonas>littlebobeep: everything in live-bootstrap is reproducible <stikonas>everything is checked against an earlier recorded hash <stikonas>well, you run it once, record checksums and commit them to the repo <stikonas>those checksums are then checked when live-bootstrap runs <littlebobeep>how do you checksum when you don't have a checksum utility compiled? <stikonas>littlebobeep: stage0-posix already has sha256sum utility <stikonas>so that's not an issue for live-bootstrap <stikonas>.links is a list of symlinks that we create for that package, most are empty <stikonas>littlebobeep: we have a few, first one comes from stage0-posix, then later from coreutils <stikonas>you can write sha256sum for baremetal bootstrap too <littlebobeep>when you say "comes from stage0-posix" what toolchain compiled this inital sha256sum and when is it first used? <stikonas>it's used at the end of stage0-posix to check all binaries of stage0-posix <stikonas>littlebobeep: that's sha256sum from coreutils <stikonas>sha256sum from stage0-posix is slightly more limited (supports up to 2MiB binaries) and slower <littlebobeep>No I am talking about the 14+ things before the sha256sum from mescc-tools <stikonas>well, we only check sha256sum after sha256sum is built <stikonas>you can't prove consistency from within the system, you need to do it externally <stikonas>to prove that sha256sum is not malicious you would have to check stage0-posix sourcecode as well as inspect bootstrap binaries ***furrymcg1e is now known as furrymcgee
<fossy>stikonas: merged, what was the workaround? was it the removal of mes/m2.c? <stikonas>I guess it's less buggy than mes-m2 that was compiled with M2-Planet <stikonas>I removed m2.c just because it's not necessary when compiler is mescc <stikonas>yes, I don't see why your changes caused it <stikonas>but well, mes is faster and less buggy than mes-m2, so probably fine to build it <fossy>yeah, not the end of the world thoguh <muurkha>hmm, what was the first version of GCC that has parts written in C++? <fossy>or maybe that was the last one without <muurkha>which suggests sometime in the 02010-02013 time period <fossy>oriansj: i was trying to run stage0-posix on tilck (smaller linux-compatible-ish kernel) but stage0-posix binaries do not execute properly -- https://github.com/vvaltchev/tilck/blob/master/kernel/elf.c#L143 they get caught by this trap. i'm not familiar enough with the elf format to understand this exactly; what is going on here, and how can we rectify them to make the two compatible? <stikonas>fossy: all binaries or just hex binaries before blood-elf? <fossy>kaem-optional-seed didn't work so i tried final kaem from M2-Planet. same error <fossy>haven't tried those yet, but tcc is said to work in the readme <fossy>mescc uses M1/hex2 under the hood iirc, so i would imagine it has the same issues <stikonas>I suggest trying, so that we know exactly when it starts working <stikonas>well, it depends on what header hex2 attaches <fossy>it seems to be some behaviour that is slightly out of spec but linux kernel does not care about <fossy>or tilck requires behaviour subset of spec <stikonas>at least none of the binutils complain about that format eithre <oriansj>littlebobeep: yes building a kernel with bare-metal M2-Planet would be for solving the POSIX bootstrapping problem <oriansj>fossy: well fortunately it is easy to figure that out if you are willing to do some tests for me <oriansj>expected behavior is to return 42 and nothing else <oriansj>and perhaps have what compiler they do have running on that host build return 42 and share the xeh results of that file for us to figure out what possible differences there are <vagrantc>janneke: trying out your mes patch, thanks! <mihi>fossy: I would try to replace the ph_vadddr in line 35 of oriansj's paste by 00 10 00 00 (4096 in little endian) and try if it helps. If not, probably you need to pad the section (i. e the part from ELF_base to ELF_end) so that it is 4KB in size. <mihi>btw janneke, oriansj, congrats for the new releases :) <mihi>As far as I know, M1 does not support anything like the DUP directive, so if the sections really need to be padded to multiples of 4KB, probably a postprocessing tool similar to blood-elf would be required. <vagrantc>janneke: and the patch works for me! yay! <janneke>it's kind-of ugly, but i wanted a simple fix <janneke>vagrantc: note that on x86, gcc is optional if you have m2-planet ;) <vagrantc>janneke: don't have m2-planet in Debian yet, and got a little lost trying to figure out how to actually package it :) <vagrantc>and, well, gcc is assumed to be available for Debian packages... <vagrantc>so i can't not have it, more-or-less ... someday, in the distant future, perhaps coding from another star system, debian might actually be bootstrappable and that assumption could be dropped :) <vagrantc>even though for a long time guix had a largish bootstrap seed, it actually kept track of what the exact seed was, and could systematically work to replace it piece by piece <fossy>oriansj, mihi: thanks for the pointers, i changed ph_align in oriansj's paste to 00 10 00 00 and that made that run <bauen1>vagrantc: i've played a bit with compiling dpkg, and i will probably try to modify the "core" (build-essential, Essential: yes) packages to form a non cyclic dependency path based on some packages derived from live-bootstrap <fossy>now, let's try kaem and hex0 <bauen1>as in compiling dpkg, debhelper from live-bootstrap <vagrantc>though i was more talking about moving debian to actually someday bootstrap itself from a known set of packages <vagrantc>but very interesting to take little steps first to get there :) <bauen1>vagrantc: there is actually little problem compiling dpkg, debhelper, dh-autoreconf, dh-strip-nondeterminisim, tar <mihi>but yes, I agree, better to start somewhere simple instead of looking at the big problems first... <janneke>vagrantc: no worries...but i figured it was nice to know <vagrantc>janneke: indeed, it's great to have multiple options :)