<stikonas[m]>And some things are suitable for guix, e.g. builder-hex0 or stage0-uefi <vancz>that command line is generated by some nix scripts trying to build mes, or something, I'm not sure, I'm just helping <vancz>afaict the syscall.h headers that define that symbol are listed in the -f so I have no idea why its giving that error <vancz>mescc and stage0 are both set to master, I'm trying to update the scripts that generate that command. It started failing when I updated. <oriansj>vancz: well the error is rather straight forward SYS_brk is not defined in /nix/store/0b9czimq3v8z55rl762b8zgl3s6ppla1-source/lib/linux/brk.c on line 29 which if I remember correctly was caused by people using meslibc instead of M2libc for the building of Gnu Mes with M2-Planet <vancz>yeah I can see the error but I have no idea why it's erroring, afaict from reading these source files the symbol is defined right there... <vancz>but I dont understand how these tools work <vancz>is there some behaviour I don't know? <vancz>specifically I would have expected this sequence to fulfill it: <vancz>-f /nix/store/0b9czimq3v8z55rl762b8zgl3s6ppla1-source/lib/linux/x86-mes-m2/syscall.c -f /nix/store/0b9czimq3v8z55rl762b8zgl3s6ppla1-source/include/linux/x86/syscall.h -f /nix/store/0b9czimq3v8z55rl762b8zgl3s6ppla1-source/include/linux/syscall.h -f /nix/store/0b9czimq3v8z55rl762b8zgl3s6ppla1-source/lib/linux/brk.c <vancz>/nix/store/0b9czimq3v8z55rl762b8zgl3s6ppla1-source/include/linux/x86/syscall.h exists and contains "#define SYS_brk 0x2d" along with include guards <vancz>so unless another file ends up defining __MES_LINUX_X86_SYSCALL_H ... ***Server sets mode: +cnt
<oriansj>see when one uses --bootstrap-mode with M2-Planet #define lines just become a comment and // CONSTANT SYS_read 0x03 lines actually become running code <oriansj>and several features of M2-Planet are turned off <oriansj>the order of the .c files can matter as M2-Planet treats multiple input files as a single concat'd file and if it hits something undefined it will throw an error. <oriansj>yeah, your build command is missing files like: -f lib/linux/${mes_cpu}-mes-m2/_exit.c, -f lib/linux/${mes_cpu}-mes-m2/_write.c, -f lib/stub/__raise.c, -f src/m2.c and seem to be using -f src/cc.c instead of src/m2.c and would have build issues because of it as well <oriansj>the kaem.run command is essential when bootstrapping <vancz>though, even with the CONSTANT thing, that file is still there in the list <oriansj>and the link between mes.c and M2-Planet is very touchy <vancz>Ok, I'm going to get some sleep now, thanks! I'll pass this on. <vancz>oriansj: Ok actually, one more thing. I have a case of m2-planet segfaulting in https://paste.debian.net/1253261/ (WHILE_handle_define_2), though its about a year old version of the upstream repos IIUC. <vancz>Do you know anything about this? <oriansj>well that would be a while loop in the function handle_define which is part of the C macro functionality <vancz>Yeah, that's about as far as I got. <oriansj>which means there was a #define macro that caused it to walk off the end of the input list <oriansj>and I did find a few of those while fuzzing and cleared those out but there may be more yet unfound <vancz>well, it's also not the latest code so it may be a crash that's solved in an existing patch <oriansj>well fortunately it would be trivial for you to test <vancz>I got into the whole mess above by trying to update... <vancz>unless you mean something else <oriansj>as M2-Planet built locally via git clone can just be passed the same arguments and it should produce the exact same output (or in your case an error message) <oriansj>and if it does segfault, I can use the file(s) to figure out the why of the segfault and fix it for you <oriansj>usually only takes me a couple of minutes with a segfaulting test <vancz>yep, well at least it's not crashing now <vancz>//nix/store/ind2yfndjd5sffx9ndcb55f6f73pmrlv-source/POSIX/M2libc/amd64/Linux/bootstrap.c:29: <vancz>so probably some messup with the deps <oriansj>vancz: well when using --bootstrap-mode FILE is defined inside of M2-Planet but without it, you need to -f M2libc/stdio.c to include the definition of what FILE is <oriansj>before your use FILE in your code of course <oriansj>the probably most annoying bit of M2-Planet is you have to define things (or prototype them) prior to use (which is just C being super strict) <vancz>luckily I'm not writing any of this <vancz>its very helpful that you were around <oriansj>well I'm usually on everyday, so even if I am not online, I am usually able to respond within 24 hours <oriansj>feel free to dump questions and people online will answer if they can and I'll certainly help how I can when I get online. <vancz>Ok this command just seems generally screwed <vancz>this whole thing probably needs to be rebuilt to the example <vancz>or I'm adding the wrong things in the wrong spot <oriansj>well the order of the -f files matter *alot* <vancz>also stdio.c is -f-ed twice and I expect the first should be a .h? <vancz>//nix/store/ind2yfndjd5sffx9ndcb55f6f73pmrlv-source/POSIX/M2libc/stdio.c:37:Received int in program <oriansj>vancz: you don't want to use --bootstrap-mode with M2libc/stdio.c <vancz>sleep attempt #2, talk to yall later. <oriansj>you probably mean / when you put /// <oriansj>and I don't think mes.c is compatible with M2libc right now; so you'll have to leverage meslibc which only janneke is really familiar with. <markjenkinssksp>a bunch of days ago I had a memory of coming across a hobby C++ compiler that claimed to compile newer GCC, but I know believe my memory was faulty <sam_>not thinking of cproc which is a C compiler? <markjenkinssksp>which is said to compile one of the late GCC versions written in C before the C++ transition <markjenkinssksp>taking cproc and its deps and doing a rewrite to a imparitive, memory safe, dynamic typed, byte code interpreted, early bootstraped lang is a long off fantasy project of mine <oriansj>markjenkinssksp: well one also has to bootstrap qbe as well to use cproc if I remember correctly <markjenkinssksp>I would consider that a comforting abstraction, allows for breaking the problem down and starting low level and then building upon it <markjenkinssksp>still making a little headway on the current hobby project way further down the stack, worked it over a bit today while waiting at a clinic <oriansj>honestly, I'm still working up the courage to restart M3. Because it is a very big thing and it is hard for me to find large blocks of time to work on it <markjenkinssksp>I don't really expect to solve the yacc licensing problem with my odd approach before gash gets enough bash compat, but I'm scratching other itches while at it too <oriansj>markjenkinssksp: who cares if someone beats you to a solution if it is fun to work on? <markjenkinssksp>because you are a mad god programmer in imperative style oriansj, I do hope to give you a better imperative lang to work with on my roadmap, but who knows how fast that will happen or if what I put out there turns out to be a lang you'd like to use <oriansj>besides the more possible bootstrapping paths the better. <markjenkinssksp>and so I don't really see it as a race or anything like that, somebody will get there first, but I'll be interested in what I'm working on either way <oriansj>and removing both mes.c/mescc and TCC from the bootstrapping path feels like unneeded overkill <markjenkinssksp>If, and it's still a big if, but if I manage to write a parser generator that's bootstrappable, I do wonder if folks will think I'm on an interesting track or if folks will just see me as doing challanging work with a lang otherwise too challanging to use <oriansj>markjenkinssksp: well not everyone agrees on what is interesting or what is challanging and you'll likely find a few people who find it interesting and a few who just find it challanging. <markjenkinssksp>I think you're right oriansj about the overkill, though part of me in the long run would like it if we had less performant bootstrap paths that minimized the amount of arch specific code, I do feel bad for folks having to do a lot of arch specific assembler, arch specific work in M2planet, arch specific work in mescc, arch specific work in tcc <markjenkinssksp>all the work folks are doing though in assember will have nice performance for common archs <markjenkinssksp>mescc is a super big win on both the inspiration front and diverse double compiling front <markjenkinssksp>and perhaps even the audability front, if scheme folks feel like they understand it and can grok it quickly <oriansj>markjenkinssksp: indeed MesCC certainly gave us a rope bootstrapping path for x86 and hopefully when more architectures are supported that it'll provide a robust path for all Guix bootstrap architectures. ***lukedashjr is now known as luke-jr
***blockhead_ is now known as blockhead
<oriansj>muurkha: I guess cc_* would be #7 and and M2-Planet would be #2 <muurkha>cc_* would be Chez Scheme and M2-Planet would be the Swift compiler? <oriansj>muurkha: #7 Forget tradition and implement everything directly by hand and #2 Use compiler-friendly languages, by which he is really taking about languages that are good for implementing compilers <muurkha>oh, not Specimen #2 and Specimen #7, but Variants #2 and #7 <muurkha>sure, Scheme is a Lisp, and it's easier to write compilers in Lisp than in C <oriansj>I wonder if anyone wrote an ML in C before