<fossy>pder: stikonas I agree we should do the suggestion of stikonas a couple of minutes ago <stikonas>exec bash run2.sh; then echo Bootstrapping complete and exec bahs ? <ullbeking>Hey all, I've been out of the loop due to a job application (it's turned into something gone sideways). <ullbeking>I noticed mention of scheme on the projects page <ullbeking>I wonder what you think of R7 large? I'm still trying to figure it out <ullbeking>I just posted sth to emacs-devel as I'm trying to create a minimal gnu Emacs <stikonas>not idea about scheme and R7... Somebody else might know better... <stikonas>well, scheme was involved in ocaml bootstrap <ullbeking>but in any case i am focusing on improving my c++ yes <fossy><stikonas> exec bash run2.sh; then echo Bootstrapping complete and exec bahs ? <ullbeking>i was introduced to some interesting and simple bootstrapping projects, i need to look back over my logs ***xwvvvvwx- is now known as xwvvvvwx
<OriansJ`>ullbeking: well r7rs large it an attempt to provide a proper standard for scheme covering the sorts of things needed in real large programs. Much akin to the Common Lisp Standardization effort. <OriansJ`>In some ways it is flawed (personal perspective) but in other ways it is potentially a path forward for Scheme to allow it to become something more than just a language where nothing serious you write can be assumed to work. <OriansJ`>ullbeking: from an implementation standpoint only. <OriansJ`>ullbeking: it is a good second approximation of the features that scheme needs. Fixing several of the more serious problems from r6rs *ullbeking is looking for his notes from previuos detailed discussion here <stikonas>although, maybe I should try to avoid if possible... <fossy>Can we recreate it using configure <stikonas>well, let me see if I can do something... <stikonas>fossy: Configure needs recreation first and it's not autotools... ***puckipedia is now known as puck
***mephista is now known as spicy_icecream
***janneke_ is now known as janneke
<fossy>i am going to assume that the bootstrap kernel is newer than 4.20 just for now <fossy>wait i dont need to know that <stikonas>pder: can you also update README.rst? just that one paragraph where it mentions that we'll soon have interactive bash. <stikonas>either delete it or write something else <pder>stikonas: I pushed by bash branch with the changes requested <stikonas>pder: I flagged a couple of more changes, unless you pushed after that <stikonas>pder: looks good. I'll merge later in the evening (in a few hours) <stikonas>at some point it would be good to create dot dependency graph... <stikonas>pder: maybe you can do "fake" rebase and push to retrigger CI? <stikonas>something like "git commit --amend" I think will do <pder>hmm, I did that earlier. Ill try again <pder>stikonas: It might be nice to set a prompt for bash, but I think we need env from coreutils <pder>something like exec env PS1="\w # " bash <stikonas>pder: should be possible to build now with musl <stikonas>alternatively, just wait until I'm done with perl and then let's build coreutils 6 (or newer properly) <stikonas>pder: we might also need hostname later... <stikonas>although, again, maybe just rebuild coreutils with autotools... <stikonas>I'll try to work out newer autotools over this weekend <stikonas>pder: hmm, so you were right, CI indeed fails with exec bash :( <stikonas>expect -exact {not syncing: Attempted to kill init} <stikonas>and only then looks for Bootstrapping complete to decide if it's fail or pass <pder>I was looking at the gawk error when running autoconf-2.52 so I tried a newer gawk and the error goes away. gawk-3.1.7 <pder>Unfortunately autoconf-2.52 doesnt work with this newer gawk though <stikonas>pder: can you try to add conditionals to expect script? <stikonas>so that both "not syncing: Attempted to kill init" and "Bootstrapping complete" are accepted <pder>I'll have some time later tonight to look at that <Hagfish>maybe linters need a check which complains about easily confusable variable/function names, or similar long hex strings appearing in the code ***ChanServ sets mode: +o rekado
<Hagfish>"We rebuild tcc against new musl and without a patch to ignore duplicate symbols." <Hagfish>the only thing "abnormal" about it is, of course, that most gnu/linux software assumes gcc/glibc rather than tcc/musl <Hagfish>it does feel like the impossible steps have been done, though, and now it's just the "paperwork" of building gcc on tcc <Hagfish>also it's interesting that the process has as many steps as the US has had presidencies :) <pder>Hagfish: those patches against musl and tcc regarding symbols were really just to workaround some deficiencies with "tcc -ar" vs binutils ar, so a detour was needed to build all the dependencies of binutils and finally binutils itself before having a proper tcc musl toolchain <pder>If tcc -ar were fixed, it would eliminate some steps and workarounds <Hagfish>it's good to litter the bootstrapping trail with breadcrumbs that can attract contributions from other skilled developers who later see this work and wish they had been part of it :) <fossy>stikonas: pder in all likelihood you can just kill on bootstrapping complete <stikonas>fossy: wouldn't that fail if bootstrapping fails with some error? <stikonas>qemu will keep running and we'll have to wait till timeout <fossy>stikonas: oh yeah good point <fossy>yeah, youre right, kill on either <stikonas>pder: actually, could it be that tcc -ar was broken because it was built with mes? <stikonas>i.e. maybe the one after musl rebuild was working, I don't think we tested that <stikonas>but anyway, it's good to rebuild with binutils too, because then we can use gnu assembler too <stikonas>which copes much better with some assembly files that musl ships <fossy>stikonas: i'm not sure that tcc has an option to not assemble <stikonas>fossy: those are standalone assembly files <stikonas>assembly that tcc produces is fine, tcc can cope with its own assembly <stikonas>musl has a bit of handwritten assembly (as I guess all c libraries( <fossy>tcc's standalone assembly support is pretty poor <stikonas>yeah, so it was choking on a few opcodes <stikonas>and the others I just removed, something to do with floating exceptions <stikonas>anyway, now we have binutils and GNU as, so everything is rebuild properly <stikonas>but I'm now going back in steps a bit, looking at perl 5.6.2 <pder>fossy: I dont think we need the export PREFIX but my tests indicate we need ". helpers.sh". Does that seem right? <pder>do you think removing export PREFIX is better than leaving it in? <OriansJ`>stikonas: well a C compiler without inline assembly support is just a toy compiler. As assembly to make system calls (deal with floating point and any real libc sort of functionality) is unavoidable in C. <stikonas>OriansJ`: it's not without inline assembly support, it's just incomplete support <bauen1>tcc supports most common x86 assembly, enough to do syscalls, but not enough to support all of musls asm code relating to tls and floats <fossy>pder: well it should propagate through from run.sh <pder>OK, I updated run2.sh. The current branch should pass CI, since I removed exec bash at the very end.