<stikonas>pder: so with binutils I can drop almost all musl patches <stikonas>but all those assembly files that tcc choked upon can now just be built with GNU as <stikonas>so only set_thread_area.patch tcc_static.patch va_list.patch are needed <stikonas>and first two patches are upstreamed in newer versions of musl/tcc mob <stikonas>(just did some minor testing now and I think it works) <stikonas>if you want, you can try to build bash on top of that ***ChanServ sets mode: +o rekado_
***rekado_ is now known as rekado
<stikonas>you might need to add --enable-deterministic-archives to binutils-2.20 later in commencement.scm <stikonas>but at least let's see if this fixes 2.14 ***EDEF is now known as edef
<civodul>stikonas: the patch was originally written by Chris Demetriou, is that correct? <civodul>stikonas: there are other issues on core-updates that need fixing first :-) <stikonas>civodul: by the way, I think in live-bootstrap we'll be able to skip gcc-2.95.3, not sure if that would be interesting in guix... I.e. we might go tcc->gcc 4 <civodul>oh sure, shrinking the chain is always interesting <stikonas>well, it will take at least a week or so... <stikonas>although, I'm not sure if chain is smaller... <stikonas>but if it has fewer old compilers, it might still be simpler to port to new architectures later <civodul>yeah, it still sounds like it could be an improvement <pder>stikonas: in your musl-rebuild branch, I am looking at binutils-rebuild.sh. I think it would be clearer to just run patch manually for each of the patches we still want instead of just deleting musl_weak_symbols <pder>looking in the patches directory, I also think we dont need makefile.patch or stdio_flush_on_exit <stikonas>I'll push everything in a few hours with updated chekcums <pder>oh ok, I think I am looking at not the latest <stikonas>pder: let me rebase now... I'll pushe then <stikonas>pder: another option is to specify another patch dir and symlink wanted patches <stikonas>pder: so I think gcc 4.0.4 is buildable with minimal changes but it needs newer autoconf, so need to do more perl work <Hagfish>i don't know whether it should feel like yak-shaving or solving a sudoku, dealing with all these dependencies and the random problems they throw up <Hagfish>i guess if there's an end in sight, and you can see the progress you are making, then it doesn't feel like the problem is fractal <pder>stikonas: I am looking at the musl-rebuild branch you recently pushed- commit b54e49f66923f44. It appears to still be applying patches that I dont think you intend <stikonas>pder: yeah, I noticed it an hour ago... fixing <stikonas>I think I haven't committed those changes <stikonas>well, should be easy, just need to rerun live-bootstrap a couple of times... <pder>great, thanks. I am looking forward to seeing if those stdio flush on exit issues are resolved <stikonas>well, I didn't recompile anything else but tcc <stikonas>pder: so I've now also did some experiments (though, I didn't record exact steps and was cheating with bison/autoconf/automake), and I was able to get quite far in gcc 4.0.4 build <stikonas>it went all the way to xgcc and then failed... <stikonas>probably didn't specify where libc is... <stikonas>but anyway, just feasibilty experiment... Didn't write anycode <stikonas>and might need to rebuild stuff like gawk or sed <stikonas>pder: regarding your bash change, do we need to checksum bashbug? it's just a script basically coppied from tarball <stikonas>in similar cases with autoconf/automake we didn't do checksums <stikonas>so probably either should do all, or nothing to be consinstent <stikonas>actually, I can simplify .sh file by not creating /dev which should already exist <pder>I can remove the checksum for bashbug, so just checksum /after/bin/bash? <pder>My initial testcase of the stdio issue seems to be resolved without the patches which is good <rekado>roptat: excellent work on the ocaml bootstrap! This is really a substantial amount of work. <stikonas>pder: well, as expected since it was caused by picking wrong symbols <fossy>I don't feel very comfortable not checking binaries just because we don't use them, I'm pretty sure there's a part of bash that shells out to bashbug <roptat>rekado, most of the work was done by nore ;) <fossy>stikonas: pder I forgot bashbug was a trivial script (not autogened) so nvm <fossy>I really should be subd to that ml <stikonas>yeah, I think we should also write to that mailing list when we bootstrap gcc in live-bootstrap... <stikonas>especially if we get newer gcc than in guix <pder>I think our build function would benefit from using named arguments. Something like build checksums=pass1 script=foo.sh <pder>Currently if you want to override the 4th argument you have to specify values for the other 3 <rekado>nore: also to you: I’m impressed with your work on the ocaml bootstrap! I think it’s amazing. <rekado>like civodul wrote in #guix it would be a lovely next step to turn this into a proper language for Guile, using its compiler tower. (Not really bootstrap-related.) <pder>I havent tried it with our version of bash, but something like build() { local script checksum\n local "${@}" ... } <fossy>pder: yeah, I am unsure if bash supports that <fossy>perhaps a rearranging of the arguments might be better? <pder>ill play around with it, I was hoping to avoid positional arguments <pder>stikonas: I pushed my bash branch which is based on musl-rebuild and things look good so far <stikonas>pder: I think after "Bootstrapping is complete" we can try to run "bash" <stikonas>but if you run manually, you'll get a prompt inside qemu <OriansJ`>stikonas: Bootstrapping is never complete, only abandoned for more pressing bootstrapping work. <OriansJ`>As each "completed" bootstrap piece is just a stepping stone for greater bootstraping goals. <mihi>hello :) Still trying to bootstrap psyntax.scm (so I am that "someone here" mentioned by stikonas). From my (limited guile knowledge) testing, I got 'syntax, 'syntax-case, 'with-syntax, 'syntax-rules and 'define-syntax-rule to work. Custom ellipsis is not implemented, and neither is it fully hygienic, but should be good enough to eventually load psyntax.scm. I'm currently struggling with getting quasisyntax (unsyntax-splicing) to work. <mihi>And maybe some cases I don't know even existing may be buggy. <mihi>Syntax variable #'(t ...) is bound to a list of temporaries, and it is presumably picked up by the second t, while binding a new syntax variable with higher rank by the first t. <mihi>But what exactly all those ellipses are doing is beyond my Scheme knowledge. Any help (or pointers who describe what these (... ...) are doing are appreciated. <mihi>(I'm aware that I may be asking the wrong people here, but I'll try here first :D) <mihi>another question for janneke: I see that Mes also comes with psyntax.pp, but I was unable to load it. Is it even used, or what did I miss?