IRC channel logs

<aggi>weird, there's a few src/* missing in MES-replacement

<aggi>some others were renamed

<aggi>./x86/hex2_s.hex0 ???

<aggi>it's not as if there was no workaround for this

<aggi>i'm only wondering why

<aggi>seems i have to re-iterate over entire stage0-x86-posix for MES-replacement

<aggi>i hope it's worth the effort since Frans said his C-compiler was significantly faster than the scheme-written one

<aggi>just don't want to wait several hours whenever testing some live-bootstrap re-integration

<aggi>and there's a good chance to crunch this down into the timescale of a few minutes instead of 13hours

<aggi>seems current MES-replacement HEAD is WIP

<fossy>aggi: let me know if you manage to get linux building with tcc-0.9.27.

<fossy>when i investigated it ~2-3 years ago, it was not possible

<fossy>linux (even 2.4) had a pretty hard dependency on binutils assembly

<aggi>fossy: pardon?

<aggi>linux has not got a hard dependency on binutils gnu-as, it is/was the bootsect.S related pieces which did

<aggi>and otherwise, the linux-tcc kernel fork was published a year ago already

<aggi>fossy: linux-2.4/tccboot were known to support kernel compilation for 20years, which has been the whole idea of it since the beginning of tinycc/tccboot, although that has not been maintained at all for 10years

<fossy>agh, i will need to go back to my notes, but there -was- some problem, even with tccboot

<aggi>btw. with tccboot involved, this shifts the issue of real-mode assembly into bootloader where it belongs

<aggi>yes

<fossy>oh, right, tccboot cheats

<fossy>"In order to build TCCBOOT,

<fossy>you must first compile a 2.4.26 kernel because for simplicity TCCBOOT

<fossy>uses some binary files and headers from the Linux kernel."

<fossy>maybe one can get around this? but i didn't see anything obvious

<aggi>as said, last weekend i've managed to support two more asembles, as86 and yasm, which i said merely shrinks the cirular dependency graph involved

<fossy>ah, sure

<aggi>well, i wouldn't call TCCBOOT was cheating, it shrinked merely shrinked the circular dependency graph, and tcboot never claimed to address the issue which live-bootstrapped managed to

<fossy>fair point, that was just when we were assessing and thought it could work for a first kernel, but we discounted it after we found that

<aggi>what i'm trying to accomplish/finalize now, is to shrink the dependency graph of live-bootstrap itself

<aggi>to get up and running a floppy-sized-<linux|fiwix>.img type of thing with kernel+busybox+tcc+as86/yasm up and running compiled in a few minutes instead of 13hours

<fossy>yes, sure, that makes sense

<aggi>ok, fossy, since you're online

<aggi>Frans isn't; and i'm having a little trouble with the current state of MES-replacement

<aggi>it seems Makefile/kaem pieces to re-integrate are simply missing

<aggi>no clue if anyone had a look at it yet, but to my knowledge Frans did launch a _complete_ stage0 including his generated src/tcc_cc.sl (and a few other missing since there is no makefile nor kaem script for this)

<aggi>otherwise, the default mescc-tools/M2-Planet/MES-libc seem complete and passing

<aggi>i am re-iterating over each single kame, make, and source-file indidividually to grasp the whole picture of this

<aggi>since, of cause, i did notice there is a few more initial hex/binary seeds involved than builder0 and what's shipped with bootstrap-seeds

<aggi>which is anything with the ending *.hex<0|1|2>

<aggi>i havent got a tiny-bootstrap.git repo ready for git-push yet (i hope and there probably will be end of this week, although I am in no hurry since TinyCC/OS itself is in good shape otherwise)

<aggi>but bootstrapping a minified TinyCC/OS release variant too is blocked until, well it's done alltogether

<aggi>*publishing a minified TinyCC/OS release is blocked until then

<aggi>so i would appreciate feedback if anyone got a clue of the status with MES-replacement

<aggi>which is, if it did work or didn't, since the current shape of this git-repo is missing a few pieces

<aggi>on his web-site Frans says it did pass, but i could NOT yet confirm this

<aggi>and a parallel review of stage0 and MES-replacement, well, isn't too easy and a little annoying TBH

<aggi>then there seems some changes made to M2libc recently by stikonas which refactored some codepaths surrounding fputs()

<aggi>seems here that's broken with git HEAD from stage0-posix-x86, although i could be wrong about this

<aggi> +> ./x86/artifact/cc_x86 ./x86/artifact/M2-0.c ./x86/artifact/M2-0.M1

<aggi>fputs is not a defined symbol

<aggi>well, ok, maybe a bisect suffices in this case

<aggi>ok; M2Libc $ git checkout 300c17668cd137b3d343a07189cefac1fd94c317 . # this helped a tad bit with M2Libc

<aggi>fossy: this means BOTH are a little unstable currently: regular stage0 AND MES-replacement

<aggi>on their master branch HEAD (not some devel branch), sorry to say so

<aggi>so, mescc-tools-mini-kaem.kaem DONE.

<aggi>the variant from MES-replacement differs significantly (tools-mini-kaem.kaem)

<aggi>i do not know why Frans had re-implemented this in particular, because the default didn't seem problematic

<aggi>then he's done check-tools.kaem for his verification - something i might skip for now

<aggi>but i do need some pieces still to arrive at /usr/bin/tcc_cc

<aggi>then there is ./usr/bin/stack_c and and various generated *.sl such as tcc_cc.sl

<aggi>i see, initially there was some ./old/stack_c.cpp implemented, which then was re-implemented as stack_c.c

<aggi>and this utility may generate/process various of those *.sl/hex0 which a makefile or kaem script is missing for "only"

<aggi>i think it may be possible to use $ tinyroot/x86/artifact/M2 to compile stack_c.c

<aggi>but i am not yet sure what Frans intended to accomplish with it, because he re-iterated with tcc_cc beginning at hex0 again, i'm confused

<aggi>another minor peculiarity, for example, there is some hex2-0.elf binary, same with kaem-0.elf interpreter

<aggi>but those are re-compiled from hex2.c etc.; maybe unnecessarily, for some unknown reason

<aggi>and the M0/M1/M2 combination of macro-expansion and c-compilation at first glance is a little confusing

<aggi>then i was tracking each source/hex file individually, by copying them manually

<aggi>catm/M2 however seem to not complain if any #include <?> was missing, so i gave up finally with this approach at Phase-7 and did a cp M2libc/* into <chroot>

<aggi>next step, trying to compile tcc_cc.c/stack_c.c (and/or mes-c compiler)

<aggi>i don't know yet what the compile-time performance-penalty of mes-c was in comparison to tcc_cc.c

<aggi>regardless of any compile-time performance gain, tcc_cc.c/stack_c.c seem to involve a smaller dependency graph (in comparison to the scheme-variant) for review overall

<stikonas>you shouldn't use random m2libc commits with stage0-posix

<stikonas>use whatever git submodule points to

<aggi>ah, ok, i avoided git-submodule alltogether

<stikonas>anyway, I'll bisect

<stikonas>probably one of the gtker's commits

<stikonas>yeh, it is 5bc82bf325327afb58c4fd00292e099502cece9a

<stikonas>This means that users must now include the arch specific .c file first

<stikonas> and then the general bootstrap.c.

<aggi>so far commit 300c17668cd137b3d343a07189cefac1fd94c317 of M2libc was working with HEAD of all else (compile time and run-time of blood-elf/M2 etc being executed)

<stikonas>well, that seems like intentional breakage

<stikonas>and whenever stage0-posix bumps M2libc version, it will have to be updated

<aggi>i can't do any other than x86 yet

<stikonas>yeah, it all works with M2libc/main if you follow what gtker's commit message says

<stikonas>the whole stage0-posix successfully finished

<aggi>well, ok, there's many commits in between, it's probably not much necessary to change in mescc-tools.kaem somewhere

<aggi>but i haven't got any known-good working baseline yet, and i rather not change anything until then

<stikonas>stage0-posix git master is working

<stikonas>just follow README.md and it will work

<aggi>seems M2-Mesoplanet/M2libc themselves are rather capable as libc and compiler

IRC channel logs

2026-03-04.log