<stikonas>well, I can try to see how final kaem source would look like <stikonas>fossy: ok, I think it's more work than gain with tcc... <fossy>stikonas[m]: i emailed bruce korb (current & original autogen developer) abt bootstrapping autogen <fossy>we shall see if we get a useful response <Hagfish>that's cool, it would be interesting to hear anything you learn <gbrlwck>stikonas[m]: thanks for the clarification! with "moving those required functions" you mean the ones in syscall.c and mini.c? <gbrlwck>huh. inserting "#DEFINE SYS_brk 214" right into the file where it's used did not help (at all); but when running M2-Planet without the --bootstrap-mode option actually works smoothly <gbrlwck>well. not "smoothly". it runs through, but resulting m2/mes.M1 is empty ***xentrac is now known as muurkha
<gbrlwck>and what does WHILE_handle_define_2 do? we load 1 into a0 and then compare a0 to 8? M2-Planet crashes there (when run in gdb) when trying to compile mes-m2 <gbrlwck>is M2-Planet really capable of handling preprocessor substitutions? <gbrlwck>M2-Planet --bootstrap-mode --architecture riscv64 -f test.c <gbrlwck>gives: test.c:4:ANSWER is not a defined symbol <gbrlwck>same answer without the optional arguments <stikonas[m]>gbrlwck: @8 means 8 encoded for RISC-V S type instruction <stikonas[m]>WHILE_handle_define_2 is probably just some label generated by M2-Planet <stikonas[m]>so maybe something is bad with defines, I haven't looked at that part of M2-Planet <stikonas[m]>but in principle, the more stuff we have in M2llibc, the more capable M2-Planet would be <stikonas>not sure why I initially wrote that inefficient code... <fossy>well, i got an answer, not very useful <fossy>"You'd have to go back to _very_ early 4.x versions before Guile was used as an extension language. (Versions 1, 2 & 3 were all shell scripts dating back to the early 1990s.) " <fossy>"The only way to "break" the recursive dependency is to add generated files to the repository." <muurkha>I'm missing the context of which program this is <muurkha>and the second quote means that 4.x can't be built with 3? <fossy>I don't think so, I think it just means that this developer dosen't really understand the premise of bootstrapping <fossy>I think he means per-release, the only way to stop users from requiring autogen to build autogen is to add generated files <fossy>I have no fscking clue where to find these sources though <muurkha>maybe that developer knows. was it a gnu project? <Hagfish>nice to have got an answer, but yeah, a pity they didn't realise the limitations of their work <oriansj>gbrlwck: --bootstrap-mode is for cc_* compatibilty reasons. Generally programs are not supposed to use it. <oriansj>if you use #define and remove --bootstrap-mode, it works with defines just fine <fossy>muurkha: hm, it would seem so <muurkha>(earlier versions might have been previously present and just getting purged) <stikonas>and I am confused why we have to go beforre Guile was used... <stikonas>Guile might complicate things a bit, but for bootsrapping purposes we have it <oriansj>I'll be updating stage0-posix shortly <oriansj>muurkha: one might say bootstrapping requires one first to admit all programming sins and work to address them. <stikonas>oriansj: oh, I have stage0-posix almost ready <stikonas>although, if you want, you can do it.... <stikonas>and I guess we won't be able to get GCC people to stop using autogen... <oriansj>stikonas: M2-Planet just uses the M2libc library <oriansj>so I just needed to update M2libc in stage0-posix to update the output binaries <muurkha>oriansj: hahaha, that's a bit more of a messiah complex than I'm comfortable with assuming <stikonas>muurkha: still, you can probably agree that autogen case is annoying... <fossy>stikonas: neither am i, i don't understand what guile has to do with it <fossy>I'm trying to find working tarballs of these old versions <stikonas>although, even version 1 might need some rewriting <fossy>not sure what exactly i'm looking for yet tbh <stikonas>and probably more complicated than perl 5.000 <fossy>i'm attempting cvsimport again, but i'm not sure if that will do anything <fossy>my limited cvs experience is telling me that the original cvs repo might be also messed up <fossy>probably, but that's well and truly gone whatever was before cvs <stikonas>and I can't find any older tarballs than autogen4 <oriansj>muurkha: well there is no where for anything to hide if everything must be built from source. And ugly tricks like what Bison did like depending on a new feature implemented in that feature instantly become obvious to everyone. But if you are referring to me having an ego; I certianly hope I didn't come off that way. <stikonas>fossy: 4.5.3 is also the first one that Debian packaged <stikonas>so 1 2 and 3 might be truly impossible to find <fossy>Changelog says it was "rewritten in guile" <fossy>if it was totally rewritten, we might have a chance at that point for a non-dependency version <fossy>It's probably out best/easiest bet <stikonas>it might still have used older autogen and included pregen files in repo <stikonas>it might even be the case that completely rewriting autogen is the easiest way (but still hard)