<rekado>perhaps you can ignore them. The comment above says “Note that quasisyntax is expanded first, before any ellipses act.” <mihi>rekado, thanks for the feedback. my problem is that when I try to evaluate quasisyntax.pp with my implementation of with-syntax et al, I get a syntax error in that line "Misplaced ellipsis", which does not happen when I evaluate the same code in "real" Guile. And to debug it, it would be helpful to understand what it is doing, first. That "test-ellipses-over-unsyntax" example (already) works fine for me. But it's getting late here, so <mihi>probably will pursue this on another day :-) <OriansJ`>mihi: great to hear that you are making good progress on the guile bootstrap problem ^_^ <stikonas>pder: actually, what do you think about building bash-3.1 instead of recompiling 2.05b? <stikonas>pder: bash 3.2.57 builds with just one extra hack (#define HAVE_ALLOCA_H 1) ***mephista is now known as spicy_icecream
***mephista is now known as spicy_icecream
<janneke>mihi: if you run make check, you'll see that tests/psyntax.test is run <fossy>BTW, mainly pder, I've added stikonas as a collaborator to live-bootstrap, so he will now be able to approve and merge PRs as well (but not his own, as I already did) ***nimaje1 is now known as nimaje
***duncanm_ is now known as duncanm
<fossy>making progress on kexec-tools, it is quite.. interesting with tcc and mes libc; up to 11 patches <bauen1>fossy: any particular reason for doing that instead of continueing the chain towards gcc (=> linux) ? ***roptat is now known as roptat_
***roptat_ is now known as roptat
<Hagfish>"Lion is a formally verified, 5-stage pipeline RISC-V core. Lion targets the VELDT FPGA development board and is written in Haskell using Clash." <pder>stikonas: do you prefer to move to a newer bash, or should I create a PR for my existing branch? Does the newer bash offer anything better or necessary? <stikonas>pder: hmm, newer bash offers {} expansion Ithink <stikonas>pder: maybe you can try to move to newer bash? <stikonas>I briefly tried it, the only new problem was that alloca thing <stikonas>(I workarounded it by setting #define HAVE_ALLOCA_H 1) <stikonas>oh, and maybe just "install bash" for it instead of make install <stikonas>since it installs some prebuilt translation catalogs <stikonas>other than that I think it should be the same as before <pder>I was going to also create a PR for adding dirname to the coreutils build since we need it for gcc <pder>Do you know if there was anything else missing? <stikonas>but since we have ls, we can live wihout it <pder>dir? Is that equivalent to ls? <stikonas>well, I already added sha256sum from coreutils 6... <pder>if its trivial to add, we might as well <stikonas>then rebuilding coreutils will be trivial with autotools <pder>but newer autoconf needs newer perl? <pder>At least from reading old LFS releases, gcc 2.95.3 is more suitable for building kernels than 3.x for whatever reason <pder>Which we could easily build during our last tcc-musl build I suppose <stikonas>well, 4.0.4 should be buildable with our current tcc <stikonas>I was able to build xgcc before it errored out <stikonas>that xgcc was a bit misconfigured (didn't know about our libc) <stikonas>although, it actually could build latest musl 1.2.something <pder>I think this is where we need to be careful about gcc / binutils mismatches <stikonas>It was proably just a matter of can't find our libdir <stikonas>in /after/lib/musl/ (emphasis on musl subdir) <stikonas>but yeah, I guess there might be some incompatibility between binutils as and gcc ***efraim_ is now known as efraim
<fossy><bauen1> fossy: any particular reason for doing that instead of continueing the chain towards gcc (=> linux) ? <fossy>the goal of live-bootstrap is to complete a *full* end to end bootstrap for all parts above bios and microcode <fossy>and stikonas and pder are making progress towards GCC faster than I ever could rn <fossy>stikonas: if you have no objections, I might attempt GCC 2 soon <fossy>I would like GCC 4 but I think a GCC 2 triplet will be easier <fossy>that can probably be a first improvement <stikonas>but I still think GCC 4 might be more compatible with musl <stikonas>so it can be done before we improve perl <fossy>stikonas: do we also want to stick with musl <fossy>its probably not a bad idea unless we run into incompatibilities <stikonas>but maybe very old gcc will have more problems <fossy>But we will need glibc for bootstrapping distributions <stikonas>anyway, musl 1.2.2 compiles fine with gcc 4.4 (no patches necessary) <stikonas>I observed some incompatibilities with our bison and the one that gcc needs <stikonas>fossy: by the way, once pder has newer bash, should we start new file? run2.sh or something like that <fossy>don't you think we need newer binutils for newer gcc <stikonas>we should be able to exec into it, so that we don't need to keep old process <fossy>but then we can make a better helper scripy <stikonas>hmm, newer gcc might need newer binutils <stikonas>well, we might be able to make better helper... <stikonas>I had some problems with trapping signals, so old helpers are deliberately without subshells <pder>Didnt some stuff get stubbed out with signals in musl? <fossy>well, guix uses 2.20a or smth for gcc 4 <pder>Disregard my last statement about musl. I think the bash failures with trapping signals might be due to mes libc. Man of the signal related functions are stubs. <pder>That should go away in theory with a new build of bash ***lukedashjr is now known as luke-jr
<stikonas>oh, maybe that will fix some signal errors I saw in configure scripts too <stikonas>(or maybe it was shown by somethine else that configure was running... sed?) <pder>stikonas: so I am trying to build bash-3.2.57 and get the following when running autoconf-2.52 <pder>gawk: /tmp/ac1984598/finalize.awk:26: (FILENAME=- FNR=21774) fatal: can't redirect to `/tmp/ac1984598/finalize.err' (No such file or directory) <pder>running autoconf-2.52 in bash-2.05b works without error <stikonas>but gawk can be built very easily with our autotools <stikonas>or maybe alternatively if configure is generated <pder>I rebuilt it with latest tcc and musl and I get the same error <pder>Yeah, I think you are right. I can proceed if I ignore that error <pder>I need -D HAVE_ALLOCA_H? <pder>That did the trick. I just added CPPFLAGS="-D HAVE_ALLOCA_H" to configure <stikonas>pder: I guess we can ignore it with || true <pder>sounds good, I can try to revisit that later <stikonas>pder: so I'm retesting gcc with slightly clearner environment now. any idea about this error? <stikonas>notably this is after cc1, cpp, collect2, gcov and xgcc were created <stikonas>/after/gcc-4.0.4/build/gcc # ./xgcc --version <pder>hmm, I dont really have any ideas atm <stikonas>guix sets something called LIBGCC2_INCLUDES <stikonas>or maybe this is some musl incompatibility <pder>is this early on, or is xgcc able to build some other stuff? <stikonas>xgcc actually able to compile with -I/after/include/musl <stikonas>so it is the fact that it can't find headers... <pder>Also I think you should use CPPFLAGS instead of CFLAGS for preprocessor defines <stikonas>ok make LIBGCC2_INCLUDES=-I/after/include/musl helps a bit <stikonas>hmm, maybe we need linux-headers to build gcc <stikonas>Copyright (C) 2006 Free Software Foundation, Inc. <stikonas>fossy: pder: so I think 4.0.4 is quite feasible <stikonas>just need to sort out all autogenerated files and I guess in particular autoconf <stikonas>(skipped bison there but I think I know how to patch it too) <pder>Thats with current binutils-2.14? <stikonas>there are some linking errors when I try to rebuild gawk with gcc... <stikonas>but I think we'll be able to eventually fix it <stikonas>it's quite a bit slower than tcc though :D <stikonas>well, this gcc can compile musl-1.2.2 (both static and shared library), so probably whatever problems we have is simply not or misconfigured include and library paths <pder>gcc -v should provide some hints <stikonas>I don't think it's looking in /after/lib/musl, only in /usr/lib <pder>maybe you need to specify sysroot? <stikonas>well, I think I'll come back to this issue later... <stikonas>there are still prerequisites that I need to sort out <stikonas>also get perl into a state where it can run newer autoconf