<muurkha>which is, roughly speaking, about 8192-16384 gates or 1024–8192 4-LUTs <pabs3>yeah, very few contributors IIRC <pabs3>I tried to suggest they get funding to work on it full time, but they already have a job, didn't seem to want to change that ***ChanServ sets mode: +o janneke
<aggi>sam_: fyi, fully integrated slibtool 6 weeks ago, which does however break cross-compilation with many builds... almost forgot to test this <aggi>most errors are this "lib*.a: could not read symbols: Archive has no index; run ranlib to add one" <aggi>sam_: found it, seems AR=<ctarget>-ar must be exported explicitely <aggi>next time i'll have coffee first <aggi>with perl-5.8 (required for tcc-toolchain), there's no simple solution to support both tcc and any crossdev setup <aggi>crossdev will require a recent unmasked perl version <aggi>hence, to crossdev and bootstrap for tcc-toolchain, a first cross-compile will require a perl-update (for autotools/automake), and the proceeding tcc-toolchain a perl version downgrade <aggi>with tcc-toolchain, due to python-bootstrapping issues, the system-integration had to be detangled from gentoo-tooling anyway <aggi>ideally too, with a minified software-set, all autotools/automake/perl dependencies are detangled <aggi>i fear however, as soon as some precious software is desired, such as dev-vcs/git, a huge dependency graph is introduced <aggi>with this, replacing libressl/openssl with bearssl/bearssl-libtls is another milestone <aggi>anyway, once the crossdev use-case passes, i think the gcc47 c-only toolchain system-profile can be frozen/archived finally <aggi>to fork-away with linux-2.4/mes-libc/toybox and tcc-toolchain <aggi>reason for slibtool, initially, i hope for most/all bashism can be avoided with any bootstrapping path taken <aggi>there's still a handfull of cross-compiles failing with slibtool, nothing critical <aggi>anyway, retaining _all_ necessary rdeps and bdepts for bootstrapping _without_ any /bin/bash is another issue, with GNU buildsystem involved <aggi>hence, with tcc-toolchain bootstrapping (userspace), it's is two problems to cope with <aggi>1) full removal of GNU-toolchain and GNU-buildsystem, removal of python, perl, bash etc... <aggi>AND retaining a self-hosting system which can bootstrap/cross/compile itself <aggi>then 2) a fully detangled tcc-toolchain system must be capable to bootstrap GNU toolchain and/buildsystem <aggi>the latter is accomplished by bootstrappable, the former isn't <Hagfish>it's great that the bootstrappable project is shining a light onto other pieces of technical debt <Hagfish>it could make people really consider their tools, and find new important goals <Hagfish>or at the very least, raise awareness to help avoid making the same mistakes in the future :) <aggi>ok, this is the reasoning, to consider any upgrade path beyond gcc47 for example, void, and instead considering a ROLL-BACK strategy <aggi>and with this, just theoretical, linux-2.4 which x86 32bit hardware was appropriate for (including ao486 opensource SoC) <aggi>the most recent kernel version which addressed year2038, is linux-5.6, and this, probably, won't pass with tcc-toolchain <rickmasters>stikonas: I am confused by the catm command on line 14 here: <rickmasters>That command and the next line seem to be in the wrong current directory. <rickmasters>They are duplicated on line 25 (in the correct directory). <rickmasters>That seems like a simple cut and paste mistake but what confuses me is how could <rickmasters>anyone build live-bootstrap for the last 8 months since that was introduced? <rickmasters>I get a "cannot open" error that terminates everything <rickmasters>this is under builder-hex0 kernel but I don't see why it would be different under another kernel <rickmasters>By the way, I should say I've never run a full build of live-bootstrap under qemu with a linux kernel. <rickmasters>The friction for me was getting a proper linux kernel that would work which I believe there is no documentation for. <rickmasters>Is there a simple way I can get such a kernel? Could you help me out with suggestion for which kernel to use and how you got it? <stikonas[m]>Maybe not the obe built with allnoconfig but requirements are very minimal <stikonas[m]>Maybe there is a bug somewhere else and non zero exit code is ignored... <rickmasters>ok, I realized that I have my kernel set to terminate on error, but kaem is running non-strict so it will ignore it <rickmasters>so, it would output an error and continue like you said. <rickmasters>its not a bug, unless you intended to run kaem in strict mode <rickmasters>stage0-posix runs kaem with --strict which seems like a good idea. <oriansj>possibly a M2lic bug which results in values other than -1 being returned on error? <rickmasters>oriansj: i think you want fopen to return NULL on error. I think thats correct. errno is used for the error <rickmasters>oriansj: catm uses open which returns -1 on error, which is also correct for open <rickmasters>stikonas, oriansj: yes, the error is propagating correctly to catm and then to kaem, but it is currently ignored there. agree that --strict would help <rickmasters>stikonas: if you'd like, after the gzip PR I can test with --strict on all the kaem commands and send you another PR for that <stikonas>I was under impression that we already have strict mode <rickmasters>stikonas: well this is odd, on the linux build of live-bootstrap, I don't see an error message from catm on those gzip commands... <stikonas>rickmasters: well, that's how it was missed... <rickmasters>stikonas: kaem --strict doesn't catch it either, so something else is different. <rickmasters>stikonas: i'll keep digging. boot2now runs live-bootstrap in phases, cacheing executables between phases, maybe my catm is different, not sure <muurkha>pabs3: thanks for the note on LibreRPi! <rickmasters>stikonas, oriansj: so I noticed that gzip-1.2.4.kaem does "set -ex" at the beginning. That probably turns on --strict mode? <stikonas>rickmasters: let me check but I doubt it <stikonas>it might be for bash compatibility if you run it with bash <rickmasters>So I need track down why boot2now produces a catm error and live-bootstrap does not. <doras>stikonas: have you ever noticed these strange symlinks? <doras>stikonas: sorry, apparently I didn't paste the link originally ;) <doras>stikonas: I also noticed util-linux doesn't respect --libdir properly and places some libraries directly in in `/usr/lib`. <stikonas>probably fixed in newer versions of util-linux... <stikonas>I don't see anything in build script that would cause those symlinks <stikonas>so I think they come from util-linux build system <stikonas>I would just ignore them, they should be harmless <doras>It's in preparation for some other changes around the musl library directory. <stikonas>yeah, looks fine. I guess I'll merge that earlier PR later today and then we can merge this <doras>stikonas: I'd like to reduce our dependency on environment variables. I found at least one case where a package caught an environment variable set in our build scripts and changed its output. <sam_>what was it, out of interest? <doras>Do you think it's preferred to pass variables between bash scripts using command line arguments (such as in the `init` -> `run.sh` cases), or should each script (both `init` and `run.sh` in this case) redefine its own? <stikonas>otherwise there will be a lot of hardcoding of the same thing <stikonas>though I thought that in most cases environmental variables are not exported <doras>sam_: I tried to add LIBDIR in additional to our existing LIBDIR and it resulted in bison changing one of its man page outputs. <doras>stikonas: I removed some environment variables some months ago, but there are quite a few more. I won't get rid of all of them, but I'll do one more iteration <doras>Specifically I'm after PREFIX/SOURCES/SRCDIR/DSTDIR and friends. <stikonas>yeah, but ideally try not to have it hardcoded in more than 1 place <doras>I want to add LIBDIR in a future PR to avoid a lot of existing duplication that we have. <doras>stikonas: ideally once per system. <stikonas>maybe some can be renamed to avoid clash with commonly used names that affect packages <doras>I think it's best to remove them from the environment entirely if possible. Plan B can be a rename. <doras>I'd be surprised if SOURCES or DESTDIR aren't already caught by some package accidentally. <doras>Sorry, I meant PREFIX or DESTDIR. <doras>Even if it gets us the result we wanted, it's implicit and hard to predict. I'd rather pass these explicitly. <doras>stikonas: how about `after.sh`? Same thing, use command line arguments? <doras>stikonas: you mean unset the ones we get from kaem? <stikonas>hmm, not sure if we should bother with that.... <stikonas>kaem variables are mostly lowercase, I doubt that they clash with anything <stikonas>I meant it should be possible to remove that export keyword <doras>stikonas: yes, this is what I'm doing. <doras>Almost done covering everything. Then I'll find out what breaks/changes hash after a bootstrap. <stikonas>I think you addressed all fossy's concerns. If there are any more, we can sort it out later <doras>Yes. I guess GitHub isn't smart enough to figure out that a clean fast-forward is possible? <doras>Oh, you also merged the dynamic linking support. <stikonas>yeah, that one can approvals from both fossy and me and no comments, so no need to wait <doras>sam_: actually, it was dhcpcd, not bison. <rickmasters>stikonas: it appears catm is getting -2 from open when the file does not exist. <rickmasters>not sure why yet, it should be -1 and it is -1 with builder-hex0 / boot2now <rickmasters>I should point out my submodule versions of stage0-posix and live-bootstrap are a few months out of date in boot2now <stikonas>I don't think we made any changes regarding catm though <rickmasters>yeah, and the open implementations in M2libc are just assembly code to invoke the kernel syscall <oriansj>yeah, it is a naked return from the kernel syscall <oriansj>so if the kernel gives it 42, it returns 42. if the kernel gives it -2, it returns -2 <oriansj>but we can tweak catm to be robust against that by changing if(-1 == input) to if(0 > input) <oriansj>but that might just be masking an error <rickmasters>My suspicion is that the kernel can return various negative errors and then libc is supposed to set errno and return -1