IRC channel logs
2023-01-08.log
back to list of logs
<fossy>stikonas: yeah, that's where my QEMU build got to as well <stikonas>fossy: so far I've just looked at bash code in PR, that looks fine, but again, I haven't checked any of the pregen stuff yet <stikonas>fossy: maybe one small note (but it's somewhat optional). All our packages start lowercase, but Python is now uppercase <stikonas>oriansj, janneke: I've briefly looked at mes-m2 build process. It might be possible to switch it to M2libc with a moderate effort. <stikonas>M2libc only needs a few extra functions and most other functions can be taken from meslibc <stikonas>the goal here is use M2libc for lower level stuff like libc.M1, lower level functions that use syscalls but some higher level pure C functions can be taken from mes (i.e. stuff like isdigit) <stikonas>that would automatically make mes-m2 available on all arches that stage0/M2libc supports <stikonas>and we won't need to dublicate all the libc.M1 functionality <stikonas>there are a few obstacles to this though, we would have to build everything with M2-Planet in non-bootstrap mode, which is mostly fine but there are some #defines that M2-Planet chokes upon <fossy>stikonas: yeah, i did think about python vs Python; i dont really have a strong preference either way, it just appears more officially/many distros use Python <fossy>stikonas: what do you think about that patch nanonyme sent? i'm not really sure about it.. it concerns me more that it fails non-deterministically, so i'm worried this patch just hides a symptom rather than an underlying issue <stikonas>fossy: hmm, hard to tell... I don't really understand why it fails <stikonas>so I think even hiding symptom would be useful <stikonas>but the patch does not apply cleanly to autoconf 2.69... <stikonas>fossy: perhaps a cheap workaround might be not to use 2.69 <stikonas>but we might not be able to use autoconf 2.71 at that stage <stikonas>I haven't seen those lowest 3 bugs though <fossy>neither, i haven't seen those for a while <stikonas>I think the only one I saw is automake 1.15.1 <stikonas>hmm, so I think macro brackets are broken in M2-Planet... <stikonas>which is somewhat annoying as mes uses it <stikonas>(not this particular one but brackets in general) <stikonas>hmm, looks like we process '(' in macros but then have nothing to process closing bracket <stikonas>and I've got mes-m2 (with M2libc) to build (with a few stubs for now). Unfortunately it still crashes, but hopefully fixable (possibly due to stubs) <janneke>stikonas[m]: yeah, there's a hack for that on the wip branch <janneke>stikonas[m]: that might be interesting <janneke>otoh mes and mes libc were initially created so that mes can be built with either glibc, or with mes libc, which is still supported <janneke>on the one hand i never understood why stage0 did not adopt mes libc, on the other hand the duplication that was created now is kind of eh redundant <janneke>but, mes libc also supports building tinycc and gcc-2.95.3, and it is groing to support gcc-4.6 <stikonas[m]>Perhaps because M2-Planet was a much simpler compiler <stikonas[m]>In any case meslibc glue for M2-Planet only supports x86 <stikonas[m]>And writing glue for other arches would be more work than using m2libc <stikonas>janneke: I guess I should rebase my work on top of wip branch <stikonas>there is already quite a bit of stuff in there that I had to add (i.e. additional #define instead of //CONSTANT) <stikonas>then of course it won't work with old M2-Planet but maybe we should move everybody to newer M2-Planet anyway <janneke>stikonas: that's what i hoped, but i needed to stay on 1.10.0 for a bit, so yeah <stikonas>it was just macro processor seeing '(', then processing what is inside but not dealing at all with ')' <janneke>i'm sorry you had to redo some of my work because it was still on "wip" <stikonas>so the fix is actually simpler than that define workaround <stikonas> 6 files changed, 48 insertions(+), 11 deletions(-) <stikonas>had to copy getenv and setenv from mes to M2libc <stikonas>so we would still be using mostly meslibc functions, but I don't need to use any of the crt/syscall/etc stuff <janneke>yeah, maybe it's a *feature* to have a mes build (use and) support m2libc for m2-planet, for mes or gcc use mes lib c, and also support gcc+glibc <stikonas>yeah, I think that would simplify things a bit <janneke>eventually m2libc and meslibc may merge, or not <stikonas>M2-Planet is quite picky and needs different glue <janneke>it makes sense for a m2-planet build to use m2libc <stikonas>maybe we can even get mes-m2 running on UEFI almost for free... <stikonas>getting it to rebuild and self-host is another matter though... <stikonas>but anyway, UEFI code in M2libc can probably be ported to meslibc too <janneke>what civodul did by adding guix packages in the initial ramdisk, was build it and print hash of the build artifacts <janneke>and then verify it's identical to a regular bootstrap build <stikonas>I guess to see if they match normal ones <stikonas>but I guess guix would always assume a running kernel and won't be doing kernel bootstrapping <janneke>that would give us a much stronger case for the normal build being not corrupted, while not having to do the entire bootstrap in uefi/initial ramdisk <stikonas>anyway, right now rickmaster's builder-hex0 is still more capable than stage0-uefi <stikonas>but the more options we have, I guess the better <stikonas>still, a year ago, we had basically 0 work on kernel bootstrapping <stikonas>and soon it would be possible to bootstrap kernel from tiny seeds too <stikonas>janneke: by the way, M2libc now has a non-trivial free, if you want you can try to steal it and use in meslibc too <janneke>stikonas: interesting, i haven't felt the need yet <stikonas>janneke: for M2libc the need came from UEFI <janneke>mes lib c should also make FILE a real struct <stikonas>in UEFI you really need to free all memory, file descriptors, etc... <stikonas>so we needed a way of tracking what is reserved <stikonas>fossy: hmm, so I don't think that patch fixes the problem, maybe it is indeed "cosmetic". Or maybe it makes random problem into deterministic <stikonas>hmm, rebased my mes-m2 with M2libc changes on top of mes "wip" branch. Unfortunately mes-m2 binary crashes... Perhaps I'm trying to do something too hacky then <stikonas>and there are too many incompatibilities between mes and M2libc (i.e. like file being struct vs int) <stikonas>still at least I found and fixed and issue in M2-Planet macro support <stikonas>and there is a similar M2_CELL_SIZE that could be (3 * sizeof(void*)) <stikonas>otherwise it will only work on 32-bit architectures <stikonas>I guess this only works with #defines and didn't work before with // CONSTANT <janneke>stikonas: ah yeah, guess that's right <stikonas>yeah, so back then we had to hardcode ourselves to 32-bit arches <stikonas>janneke: anyway, I'm a bit lost at why mes-m2 crashes with M2libc, so perhaps I'll just abandon that experiment <stikonas>I tried to run it in gdb, but it's very tedious to debug <stikonas>well, it also took you a long time to initially get it to build and run in M2-Planet at all <rickmasters>stikonas, fossy: Do you know why we have both SHA256SUMS.sources and <pkgdir>/sources with the same checksums? <stikonas>rickmasters: is the former still in git? <rickmasters>oh, sorry I'm on an older version. I think I caught it in transition <stikonas>I don't think I have it here, so probably you have an old dirty file <stikonas>now fossy wrote that checksum-transcriber tool that converts <pkgdir>/sources into format that sha256sum can understasnd <stikonas>this is mainly to make list of sources more machine readable than it was before when it was inside rootfs.py <rickmasters>Right, it's fine. I've just been working on updating to the latest live-bootstrap but I'm still on an older version. <rickmasters>I'm setting up to use the early tcc-0.9.27 build for Fiwix. <stikonas>well, I've added unbz2 and swapped the build order in the latest live-bootstrap <stikonas>so now it's building tcc 0.9.27 immediately after tcc 0.9.26 <stikonas>rickmasters: are you writing some kaem script to build Fiwix? <rickmasters>stikonas: I'll have to make sure builder-hex0 can run tcc-0.9.27. It's only run tcc-0.9.26 so far. <stikonas>hmm, true. But hopefully it's not too different <stikonas>I think in live-bootstrap we actually use meslibc compiled with tcc 0.9.26 and programs compiled with tcc 0.9.27 then linked into a single binary <stikonas>later we'll need to transfer both tcc 0.9.26 and 0.9.27 to Fiwix rootfs <stikonas>as 0.9.27 built with meslibc is not self-hosting <stikonas>there is probably some bug somewhere that we didn't figure out <rickmasters>Oh, I think I found that in the tcc-0.9.26 kaem script.