IRC channel logs
2023-12-12.log
back to list of logs
<Guest25>How can we build mescc after building stage0 <janneke>Guest25: in the Guix bootstrap we run ./configure.sh and ./bootstrap.sh; the live-bootstrap has a kaem script to build mes <stikonas>Guest25: and to be more precise, you need to build mes, not mescc <Guest25>Ok, what dependencies do I need for building mes? <Guest25>It seems it is trying to use gcc when building <stikonas>well, there are various build-systems/options <janneke>mes can be built with gcc, mainly for development purposes (and hysterical raisins) <stikonas>Guest25: are you just trying to build mes or are you trying to do bootstrap with not extra dependencies? <stikonas>if you don't want extra dependencies, including shell, then you need to use kaem scripts <Guest25>I want to build mes absolutely with no extra dependencies <Guest25>so when I build with kaem, I get mes-m2, how do I get mescc from that? <stikonas>right now you need to manually build all necessary files from mes libc and mes <stikonas>and then link them into appropriate libraries/binaries <stikonas>Guest25: note that you also need a specific version of nyacc <janneke>yes, but we'll want to keep the start of the kaem script anyway <stikonas>and also setup quite a few environmental variables <stikonas>yeah, start kaem script will have to stay there <stikonas>also nyacc contains some pregenerated header files that we can't rebuild right now <Guest25>include/fcntl.h:30:feature: #include_next unsupported in M2-Planet <Guest25>when I only have stage0-posifx in path and trying to build with mes.kaem script . I am getting error like this <janneke>also note that the mescc "executable" is just a script; mescc is a scheme program interpreted by mes <stikonas>yeah, and with no ./configure live-bootstrap creates it itself by templating <stikonas>(so replaces some variables like %prefix% with /usr) <Guest25>include/fcntl.h:30:feature: #include_next unsupported in M2-Planet <stikonas>Guest25: hmm, strange, I don't seem to see that error in live-bootstrap <Guest25>maybe not the latest, also can I build mes for amd64, or only x86? <stikonas>well, you need at least the latest release <janneke>you can build mes for amd64, but you cannot build a functional bootstrappable-tcc with that for amd64 (yet) <stikonas>I think Guest25 struggles with an earlier stage... <Guest25>so I can't bootstrap tcc for amd64 later? <Guest25>let me try the latest release of stage0-posix <janneke>stikonas: sure, but best to switch to x86 as well, right now? <janneke>for amd64, you'll have to cross-build gcc from x86 to amd64/x86_64 lateron <stikonas>I think only 1 step is not working, mes->tcc-mes <stikonas>after that amd64 should be fully functional <Guest25>Ok, let me to pass build for x86 and report the results <janneke>right, but we're still (well, guix is at least) using gcc-2.95 which is 32bit <stikonas>and I'm sure there will be other small issues for amd64 <stikonas>but the main blocker was always mes and tcc <stikonas>and now with riscv64 work we fixed quite a few 64 bit bugs there <stikonas>anwyay, mes-0.26 should work with stage0-posix too <stikonas>most likely your stage0-posix was just too old <Guest25>Now I have built mes/mes-m2. what should I do next? <stikonas>probably best to follow live-bootstrap script <stikonas>(possibly adjusting for installation paths) <stikonas>but in summary, you need to download nyacc <stikonas>I think you need at least GUILE_LOAD_PATH <Guest25>I am very sorry, but what dependecies do I need for nyacc? I am afraid of using gcc :D <stikonas>but like I warned, there are some pre-generated scheme files in it <stikonas>that are neither true source but not really binary file either <stikonas>yeah, we'll try to sort it out longer term <janneke>yeah, we'll want to generate them with mes, but that's not feasible just yet <stikonas>a bit like ./configure scripts that guix uses bootstrap <stikonas>(and live-bootstrap avoids them till autotools are bootstrapped) <Guest25>I also want to avoid using any tool from my os <stikonas>again, see that kaem script if you want to avoid using OS tools <stikonas>though you do need to download it from your os... <janneke>yeah, our bootstrap is not perfect, but it's waaay better than anything else, and it's getting better every year <stikonas>somebody in rb-general mailing list didn't agree... But it sounded a bit like trolling... <stikonas>janneke: by the way, any ideas why mes is so memory bandwidth intensive? <janneke>yeah, they had their own definition of bootstrapping and thus were allowed to use a C compiler to start with <stikonas>yeah, that sounded more like reproducible build rather than bootstrapping when you start with C compiler <stikonas>slow ram on visionfive2 risc-v board is probably the main reason why bootstrap takes a week <janneke>other than that mes is a naive, unoptimized interpreter, not an optimized compiler <janneke>and it has the poorest garbage collector that you can imagine <Guest25>error:no code for module:((nyacc lang c99 parser)) <Guest25>unhandled exception: error: (("no code for module" (nyacc lang c99 parser))) <Guest25> [c] (dynamic-wind before thunk after) <Guest25> [c] (dynamic-wind before thunk after) <Guest25> [c] (dynamic-wind before thunk after) <Guest25> [c] (dynamic-wind before thunk after) <Guest25> [c] (dynamic-wind before thunk after) <Guest25> [c] (dynamic-wind before thunk after) <Guest25> [c] (dynamic-wind before thunk after) <janneke>nyacc/lang/c99/parser.mes (from the mes installed/source tree), and nyacc/lang/c99/parser.scm (from nyacc) from the load path <janneke>it all depends on your disk layout and where you installed things <janneke>nyacc/lang/c99/parser.mes (from the mes installed/source tree), and nyacc/lang/c99/parser.scm (from nyacc) from the load path <janneke>it all depends on your disk layout and where you installed things <janneke>when not in the guix bootstrap, which uses /gnu/store paths, i use something like <janneke>~/src/mes/master/mes/module:~/src/mes/master/module:~/src/nyacc/module <Guest25>can you show again what should be GUILE_LOAD <janneke>but probably best to (also) check the kaem script <stikonas>though those will again be different than in your system <stikonas>but basically mes_dir/module:mes_dir/mes/module:nyacc_dir/module <stikonas>must be still something wrong in GUILE_LOAD_PATH <stikonas>Guest25: what if you run live-bootstrap? <Guest25>now I'm getting unhandled exception: error: (("mescc: file not found: \"x86_64-mes/x86_64.M1\"")) <Guest25>although I build for x86 and even gave x86_64-mes/x86_64.M1 file <stikonas>but somehow it tries to look for x86_64 version rather than x86... <Guest25>may be I did something wrong, let me fix it <janneke>(and you're clearly still building for x86_64) <Guest25>I fixed it, but now It searches for x86-mes/x86.M1 <janneke>good, make sure that there's a directory in LIBRARY_PATH from which you can find that file <janneke>if you use -v (or is it -v -v?), mescc will show where it's looking right now <stikonas>hmm, new mes uses so many more syscalls... <matrix_bridge><cosinusoidally> I've managed to hack my alternative tcc bootstrap path onto live-bootstrap. On my vm it reduces the time from nothing to tcc-0.9.27 from 30mins to less than 4mins (when redirecting the logs to a file since my logging is currently a bit verbose). In my version I don't build mescc. <matrix_bridge><Andrius Štikonas> cosinusoidally: am I missing something, but I'm getting cd failure when bootstrap runs cd tcc_bootstrap_alt <matrix_bridge><cosinusoidally> Andrius Štikonas: I haven't seen that, did you clone a copy of tcc_bootstrap_alt into sysa before running rootfs.py --chroot ?