IRC channel logs
2026-10-31.log
back to list of logs
<stikonas>aleksi: I looked at stage0-posix, latest release is with M2-Planet 1.13.1 <aleksi>ekaitz: /nix/store/gwijlq1b1gjy784c5rb5yc89b17q08fs-mes-src-0.28-bin/bin/mes-m2 -e main /nix/store/gwijlq1b1gjy784c5rb5yc89b17q08fs-mes-src-0.28-bin/bin/mescc.scm -D HAVE_CONFIG_H=1 -I /nix/store/40f4wihsqpm9s5dj0fjajdhw16inq74y-mes-src-0.28/mes-0.28/include -I /nix/store/40f4wihsqpm9s5dj0fjajdhw16inq74y-mes-src-0.28/mes-0.28/include/linux/x86_64 -c /nix/store/40f4wihsqpm9s5dj0fjajdhw16inq74y-mes-src-0.28/mes-0.28/lib/lin <aleksi>ux/x86_64-mes-mescc/crt1.c --> unbound-variable: (syntax->datum . #<procedure reserved? (grammar-symbol)>) <aleksi>stikonas: You're correct, I had somehow misread the output from `M2-Planet -v` <aleksi>The crt1 issue could be an incompatibility with nyacc, maybe? I'm using 3.00.0 <aleksi>Sorry to flood the chat. One more regression here - I used to write `typedef unsigned int;<newline>#define __MES_SIZE_T` into config.h on i686-linux. The reason is that otherwise types.h defines it to be `unsigned long`. And ultimately this clashes with tinycc's __SIZE_TYPE__ being `unsigned int`, which tinycc reports as a type incompatibility error <aleksi>Now, that workaround used to work well, but with mes 0.28 + nyacc 3.01.0, I'm hitting an error in decl->info, where the `size_t` part is not being recognized as a type-name rather than int-declr-list <aleksi>IMHO it's sys/types.h that's wrong here, to unconditionally typedef size_t to be unsigned long. It should be unsigned int for 32-bit and otherwise unsigned long <aleksi>Ok, with patched types.h, I have been able to bootstrap x86_64 and x86. Maybe I could submit a few of my Codeberg patches to bug-mes <ekaitz>do you use x86 compatibility for it? <aleksi>Do you mean whether we start from 32-bit x86? In nixpkgs we don't, it starts from 64-bit stage0-posix <aleksi>But there are a few compat/bugfix patches here and there <ekaitz>aleksi: that's great! you should share that with us! <ekaitz>my (very old) bootstrapping code that I have somewhere doesn't do 64 bit, i'm not sure if guix does... <ekaitz>i'll check later in detail, but please aleksi let me know how you do it <ekaitz>and what kind of changes you had to apply to types.h <aleksi>Sure, I'm working on reminding myself of how to use email with Git again. Or you can just check codeberg.org/aleksi/mes (branch bugfixes) if you prefer <aleksi>In addition to mes patches, there's a couple of tinycc-bootstrappable patches: (1) max_align_t is typedeffed in tinycc's stddef.h; (2) replace the VLA with tcc_malloc() in x86_64-gen.c; (3) remove the abort() call in x86_64-gen.c; (4) rework `ll ? 63 : 31` into in if statement in x86_64-gen.c; and (5) where tccelf.c calls fill_got(s1), do `fill_got(s1); relocate_plt(s1);` <aleksi>Oh and ensure va_list.c is included in libtcc1.a <ekaitz>aleksi: thank you. I'll read them carefully <matrix_bridge><Andrius Štikonas> ekaitz: if they work, maybe we could release mes 0.28.1? <ekaitz>sure! i have the power to do that now <janneke>and also, the process is now almost completely automated! ;) <ekaitz>yeah one only needs to run some CVS commands and that's mostly it LOL <ekaitz>aleksi: the boot-tcc is soon to be deprecated (am I right janneke) but we could use those changes if you can send them to us <ekaitz>send them to bug-mes if you want or just send them to me directly <janneke>ekaitz: that will take a couple of months to mature and release, but yeah <malina>20mbit/s diff if using std 9000 over 9710 mtu. used ot be 9194 and 9210 in some segment. or 120MB/min at ~1GB/s so 60GB transfer would save just<200ms hmm. ye ok no big deal. time to transfer a 64G file to ram from nvme on other box.ooh transferring at _exactly_ 1.0GB/s.feck forgot tmpfs is only 50% of ram. 2000J at 75% of file.or rather. 28.4s, 1180J for 31G file. hope these hold.