<stikonas>hmm, I just tried to use configure script on binutils to try it out and I'm getting problems with alloca... <stikonas> /after/include/alloca.h:39: error: incompatible types for redefinition of 'alloca' <stikonas> /after/include/musl/alloca.h:11: error: incompatible types for redefinition of 'alloca' <stikonas>I wonder why... It works for guix bootstrap... <stikonas>pder: ok, I managed to build gawk-3.0.4 , we'll see if it's new enough... <OriansJ>Hagfish: thank god we are doing manual dependency management here. <OriansJ>but to be honest, that vulnerability wouldn't have done shit if developers followed a proper code promotion process but no, lazy devs gotta be lazy and run untested crap in production. <Hagfish>or at the very least run the build in a sandbox that can only access whitelisted resources (including DNS entries) <Hagfish>anyway, i'm excited to hear about gawk 3, and that there's some work toward perl too <Hagfish>i think perl has been difficult to make reproducible in debian (but i'm not sure of the current state) <Hagfish>it might be "reproducible enough" if it only changes based on the factors which that are fixed by the bootstrapping process <OriansJ>the question is when does the Debian team pick up the ball and bootstrap dpkg <pder>stikonas: I tried removing the musl weak symbols patch and the tcc ignore duplicate symbols patches, and the tcc build fails with 4 undefined symbols including __stdio_exit_needed <Hagfish>it does feel like the computer industry is moving backwards sometimes <fossy>stikonas[m]: surely guix has some kind of patches <gforce_d11977>pder: coreutils2: the 'timeout' in CI is a real error, or just CI problem? <gforce_d11977>question to the native speakers: is correct english 'handwritten' (which sounds german) or 'manually written'? <bauen1>e.g. recently apt-listchanges in debian was orphaned by its maintainer due to lack of time ***Server sets mode: +cnt
<stikonas>well, it doesn't block all the effort... <stikonas>I have prepared gawk which is independent of it <stikonas>anyway, numbering in PR#34 needs changing now (in README and run.sh) <fossy>I spent half an hour on CRC32 in m2-planet and thats more time than I care to for an interim solution <fossy>so I just adapted the Fletcher16 Wikipedia example :) <fossy>so ill just add a -c like then checksumming will be ready <fossy>I also do not care that we do have to make it represented in decimal because I dont care about impling int -> char in hex <fossy>I mean implementing int to char (hex representation of int) <stikonas>gforce_de1977: I'm not native speaker but handwritten sounds english enough for me (I live in England) <stikonas>pder: since this weak symbols stuff is causing some problem, an option would be to drop it and manually add relevant .o file from musl when linking? <stikonas>(at least if we can't reach binutils without that) <stikonas>if we can, I would just recompile everything with ar <gforce_de1977>stikonas: England counts! 8-))) ok, i also heard "handcrafted", is this also a valid word? <stikonas>but yes, there are fewer compound words than in German... <gforce_de1977>stikonas: at the moment i'am lazy and dont do any work (homeschooling the 2 childrens) <bauen1>oh boy, someone pushed some commit to tinycc:mob that breaks self-hosting <bauen1>kind of tempted to fork tinycc for myunix, and add some heavy CI on top, and cherry-pick what i need <bauen1>could also cleanup the mess of code-styles the code currently is ._. <rain1>do you think mob wouldn't want these changes? <bauen1>rain1: style only changes are usually frowned up on (by most open source projects i know) <bauen1>on the other hand nobody can stop me from pushing to mob i think <rain1>i suppose you could do this in a fork and ask if it's wanted, making the style uniform sounds amazing <bauen1>my biggest pet peeve would be the usage of if without brackets ; yes it works and is readable until someone accidentally introduces bugs because of it <bauen1>i totally understand why they don <bauen1>*i totally understand why they don't want some of the changes necessary for the bootstrap version <pder>gforce_de1977, stikonas, fossy: I rebased my coreutils2 branch with the fixes requested. Sorry for the delay- been concerned about tcc+musl generating binaries that dont write all of their output <stikonas>pder: do you know how much everything is affected by that? <stikonas>e.g. for bison bootstrap it didn't affect me, but what about coreutils, do they work alright? <pder>Any time you redirect output or pipe the output of a command, you may not get all of the results, I think due to the stdio exit routine not getting called <pder>mihi pointed that out yesterday, but I am not sure what the correct fix is. Supposedly if certain symbols are linked, the exit routines should be called instead of the noop ones <stikonas>well, so far I didn't use pipes much, but potentially that might be breaking some configure scripts <pder>Didnt you mention something about having to build flex using mes libc instead of musl? <stikonas>pder: that was somthing to do with alloca (and I think it was m4) <stikonas>but somehow it worked out in the ned with musl <pder>I ran into the issue when running the perl configure script. It tried to test the preprocessor (tcc -ar) redirecting the output to a file, but the file was incomplete <pder>So I am sure we will run into this issue a lot <stikonas>if yes. we can try to build binutils then <stikonas>and deal with full perl bootstrap afterwards <pder>If the fix is simple in musl, I'd much prefer to have binaries properly exiting and flushing buffers <stikonas>well, potentially more things are broken <pder>do you know if tcc support for weak symbols is missing or incomplete? <bauen1>once you get binutils going, only make would be missing to build myunix i think <bauen1>now once this exam is over in 2 days i should have a bit of time to spare to work on this again <stikonas>well, with binutils we can also build linux kernel... <stikonas>pder: I don't know what's going wrong with tcc and weak symbols <pder>take a look at src/exit/exit.c on line 9 with the comment about what functions are called on exit <pder>aha, I have found a fix, but its crude. Let me see if I can simplify <stikonas>patching those lines in exit.c and similar? <pder>I reverted the weak symbols patch in musl, then tried to compile tcc and got 4 missing symbols <pder>I renamed functions in 4 places so they would resolve and removed the weak_alias lines <roptat>hi! I remember from the reproducible builds summit in Paris (2018), there was some bug in Mes at that time that managed to survive through building TCC and only became visible when building GCC (or something like that) <roptat>I think it was somewhere in handling strings, but can't remember exactly <roptat>have we wrote anything about that at the time? <janneke>roptat: ah yes indeed, what was that now <janneke>i seem to remember we wrote something about that, yes <roptat>I plan to write a paper, on the Maven bootstrap, and I think this story could help me motivate it a bit, but it'd be best if I could add a citation (and not be the only authoritative source on that story :p) <dongcarl>janneke: Is there anything I can do to help with wip-full-source-bootstrap? <roptat>like how tcc looked perfectly innocent, and worked as intended, but was actually broken since the beginning, and how hard it would have been to fix if this was an historical version of tcc that had been built in that way <roptat>with only later binaries available <vagrantc>dongcarl: there was an idea floated around to attempt to build the parts that used the guile-bootstrap binaries with mes instead and document what breaks, and maybe vice-versa <vagrantc>dongcarl: because then you could just use mes and drop the guile-bootstrap binaries <dongcarl>I may be misunderstanding completely, but isn't the goal to have hex0 as the _only_ bootstrap "binary"? <vagrantc>or at least, it's a wip coming ever closer <dongcarl>Oh I see, this will shorten the bootstrap chain, is that right? <dongcarl>Okay, apologies my brain is overloaded today <vagrantc>at least in guix, the bootstrap chain still requires the bootstrap-guile ***ChanServ sets mode: +o rekado_
***rekado_ is now known as rekado
<stikonas>dongcarl: if you want to use hex0 as the only bootstrap binary, you should look at live-bootstrap <janneke>dongcarl: actually we are currently working on wip-arm-bootstrap; the wip-full-source-bootstrap branch in guix is ready for review but "waits" for a mes release, which "waits" for arm to succeed <stikonas>dongcarl: actually, live-bootstrap still needs 2 bootstrap binaries, hex0 and kaem <janneke>if we're lucky, yt will come up with a way to have global and static arrays is m2-planet; that would allow us to clean-up the wip-m2 branch in mes a bit <stikonas>that's for mes release after arm release? <janneke>mes' wip-m2 branch probably doesn't build with gcc-10, we had to add quite some global pointers because m2-planet doesn't have static variables yet <janneke>mes-0.23 should bring ARM, mes-0.24 (if nothing in between happens) should be full-source-bootstrap/wip-m2 <stikonas>janneke: by the way, in live-bootstrap we have now managed to bootstrap bison <stikonas>although, it might be tricky to incorporate into guix... <stikonas>pder: well, initially gawk wasn't fully working, then I realized, I need to install some .awk files into share/awk/ <dongcarl>janneke: Am I correct in understanding that even with wip-full-source-bootstrap merged, we still have to download a bootstrap guile along with hex0? <janneke>the "excuse" is that in guix, we need that anyway... <stikonas>dongcarl: and also guix uses mkdir, tar, bash and xz static binaries... Although some of that can be hacked around by pre-unpacking in advance... <dongcarl>janneke: Is there any foreseeable way around that in the future or no? <stikonas>well, eventually one can try to use mes instead of guile <janneke>dongcarl: the plan is to try using mes instead of bootstrap-guile, but that is going to take some effort <stikonas>dongcarl: but if you want to have minimal environment without scheme, definitely read through live-bootstrap <dongcarl>stikonas: Will do... It will be much more useful if it hooked up to Guix though I think... <stikonas>pder: minor thing in your PR, maybe you can backtick binaries at the end? e.g. expr -> `expr` <stikonas>dongcarl: once we have toolchain, it should be possible to hook up some distros <stikonas>fossy and I were also thinking about Void and Gentoo <stikonas>dongcarl: live-bootstral is going a bit slower for now because of slightly strickter definition of "source"... E.g. using pregenerated bison/lex files or configure scripts is not allowed <stikonas>although, now bison is done, and we'll start working on autotools <roptat>btw, do you know of any academic publication around bootstrapping efforts?