IRC channel logs

2023-12-12.log

back to list of logs

<Guest25>HI
<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?
<stikonas>stage0-posix is sufficient
<Guest25>It seems it is trying to use gcc when building
<Guest25>am I wrong?
<janneke>if gcc in in PATH, it will use that
<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
<stikonas>so follow live-bootstrap route then
<stikonas>or just run it
<Guest25>so when I build with kaem, I get mes-m2, how do I get mescc from that?
<stikonas>it basically uses this script https://github.com/fosslinux/live-bootstrap/blob/master/sysa/mes-0.25/mes-0.25.kaem
<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>see that kaem script
<stikonas>perhaps later we could switch to gash
<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>i.e. M2-Planet->mes-m2
<stikonas>also nyacc contains some pregenerated header files that we can't rebuild right now
<stikonas> https://github.com/fosslinux/live-bootstrap/issues/306
<stikonas>s/header files/scheme files/
<Guest25>>>WARNING<<
<Guest25>>>WARNING<<
<Guest25>include/fcntl.h:30:feature: #include_next unsupported in M2-Planet
<Guest25>Ignoring line, may result in bugs
<Guest25>>>WARNING<<
<Guest25>>>WARNING<<
<stikonas>i.e. files like https://git.savannah.nongnu.org/cgit/nyacc.git/tree/module/nyacc/lang/c99/mach.d/c99x-tab.scm?h=V1.00.2
<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>>>WARNING<<
<Guest25>>>WARNING<<
<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>Ignoring line, may result in bugs
<Guest25>>>WARNING<<
<Guest25>>>WARNING<<
<Guest25>How can I fix that?
<Guest25>Unknown type size_t
<Guest25>include/mes/lib.h:53:
<Guest25>Subprocess error 1
<Guest25>ABORTING HARD
<Guest25>;(
<stikonas>is it the latest stage0-posix?
<Guest25>maybe not the latest, also can I build mes for amd64, or only x86?
<stikonas>well, you need at least the latest release
<stikonas>I think it's tagged as 1.6.0
<stikonas>and I only tested mes 0.25
<stikonas>I haven't tried building mes 0.26 yet
<janneke>you can build mes for amd64, but you cannot build a functional bootstrappable-tcc with that for amd64 (yet)
<janneke>so, x86 it is, for now
<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>yeah, for now best to use x86
<Guest25>Ok, let me try x86
<stikonas>janneke: or cross-build tcc
<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>oh yeah, for guix sure
<stikonas>and I'm sure there will be other small issues for amd64
<janneke>we'll want to get rid of that
<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>step by step
<stikonas>(possibly adjusting for installation paths)
<stikonas>but in summary, you need to download nyacc
<stikonas>(version 1.00.2)
<stikonas>set env variables with paths to it (see https://github.com/fosslinux/live-bootstrap/blob/master/sysa/run.kaem#L21)
<stikonas>I think you need at least GUILE_LOAD_PATH
<stikonas>possibly MES_PREFIX...
<stikonas>then you need MES_ARENA, MES_MAX_ARENA and MES_STACK form here https://github.com/fosslinux/live-bootstrap/blob/master/sysa/mes-0.25/mes-0.25.kaem
<Guest25>I am very sorry, but what dependecies do I need for nyacc? I am afraid of using gcc :D
<stikonas>no gcc there
<stikonas>you just need nyacc source
<stikonas>it's a scheme library
<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
<Guest25>ok, I thnik it's ok for now
<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)
<stikonas>anyway, just unpack nyacc
<janneke>(that's pretty great)
<Guest25>I also want to avoid using any tool from my os
<stikonas>you can even use stage-posix to do that
<stikonas>there is untar and ungz
<stikonas>again, see that kaem script if you want to avoid using OS tools
<Guest25>Thank you very much
<stikonas>though you do need to download it from your os...
<Guest25>:)
<janneke>yeah, our bootstrap is not perfect, but it's waaay better than anything else, and it's getting better every year
<janneke>or so i believe
<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>probably hard to fix though...
<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>i don't really know
<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>exiting...
<Guest25>unhandled exception: error: (("no code for module" (nyacc lang c99 parser)))
<Guest25>Backtrace:
<Guest25>  [b] (error _ _)
<Guest25>  [b] (primitive-load _)
<Guest25>  [c] (dynamic-wind before thunk after)
<Guest25>  [c] (load-file proc file)
<Guest25>  [c] (dynamic-wind before thunk after)
<Guest25>  [c] (dynamic-wind before thunk after)
<Guest25>  [b] (primitive-load _)
<Guest25>  [c] (dynamic-wind before thunk after)
<Guest25>  [c] (load-file proc file)
<Guest25>  [c] (dynamic-wind before thunk after)
<Guest25>  [c] (dynamic-wind before thunk after)
<Guest25>  [b] (primitive-load _)
<Guest25>  [c] (dynamic-wind before thunk after)
<Guest25>  [c] (load-file proc file)
<janneke>check your GUILE_LOAD_PATH
<janneke>mes should be able to find
<Guest25>what should it be?
<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
<Guest25>I'm sorry, I suddenly exited
<janneke>np
<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>(it's GUILE_LOAD_PATH)
<Guest25>thank you
<janneke>but probably best to (also) check the kaem script
<stikonas>yeah, kaem script also sets 3 paths
<stikonas>though those will again be different than in your system
<stikonas>but basically mes_dir/module:mes_dir/mes/module:nyacc_dir/module
<janneke>(y)
<Guest25>Couldn't build crtn1.o
<Guest25>same error again
<Guest25>after exporting GUILE_LOAD_PATH
<stikonas>must be still something wrong in GUILE_LOAD_PATH
<stikonas>Guest25: what if you run live-bootstrap?
<Guest25>Ok, I can try it
<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>Guest25: is that manually?
<stikonas>might be some env variable unset
<stikonas>libdir ?
<stikonas>but somehow it tries to look for x86_64 version rather than x86...
<janneke>yes, LIBRARY_PATH must be set
<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...
<stikonas>it's possibly builder-hex0 won't run...
<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><cosinusoidally> https://github.com/fosslinux/live-bootstrap/compare/master...cosinusoidally:live-bootstrap:tcc_bootstrap_alt
<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 ?
<matrix_bridge><Andrius Štikonas> oh, I didn't...