IRC channel logs
2022-09-13.log
back to list of logs
<oriansj>God is sitting in Heaven when a scientist says to Him, "Lord, we don't need you anymore. Science has finally figured out a way to create. In other words, we can now do what you did in the 'beginning'. "Oh, is that so? Tell me..." replies God. "Well", says the scientist, "we can take dirt and form it into the likeness of you and breathe life into it, thus creating man." "Well, that's interesting. Show Me." So the scientist bends down to <oriansj>the ground and starts to mold the soil. "Oh, no, no, no...", interrupts God. "Get your own dirt." <muurkha>it's usable enough that I used it to add a couple of features to itself just now <muurkha>more usable than I thought it would be at this stage, but that's not saying much <muurkha>leah neukirchen pointed out that it probably would run in MicroPython with a little bit of work <muurkha>it's about 5/8 of the size of Anthony Howe's "Ant's Editor", which is written in C <oriansj>as even SET is "usable" in the aweful sense <oriansj>but I guess it encourages short lines <oriansj>especially when every edit requires you to write the line from scratch <blockhead>everyone should write a text editor. fun, learn stuff, and it feels great when you get it working <muurkha>yeah, edumb is definitely more usable than that :) <muurkha>it has infinite undo and incremental search forward and backward <muurkha>assuming you have infinite memory anyway <oriansj>well SET was designed to edit paper tapes and work in 512bytes of memory on a 12bit processor <oriansj>although a later version supported editing of single words and moving forward and backward one word at a time. <fossy>hey doras, stikonas, regarding static/dynamic linking, i'm happy for dynamic linking to be avaliable as an option - particularly for post-bootstrap use (distros, etc). i'm not particularly convinced on using it for live-bootstrap itself however -- its much nicer to be able to manipulate the binaries into whatever "shape" you want after the bootstrap is complete <fossy>if they're dynamic any process after the bootstrap has to keep around a lot of baggage for a little while <aggi>fyi, just made a decision this morning, to roll-back to linux-2.4(2.6) with tcc-toolchain <aggi>i'll keep the frozen/archived gcc47 c-only toolchain system profile of cause <aggi>however, although almost everything from the gcc47 profile too passed with tcc-toolchain, with mes-libc a rebuild from scratch is unavoidable <aggi>pushing forward beyond gcc47 is futile, as far as the acceptance criteria of mine are concerned <aggi>and then, why not, roll-back linux kernel to something which is known to be supported with tcc-toolchain, linux-2.4/x86? <aggi>problem solved, i keep the gcc47/linux-5.10 profile archived/frozen, and with tcc-toolchain just roll-back another 10years <aggi>let's see how far i can proceed with mes-libc/tcc-toolchain/linux-2.4(2.6)/toybox-userspace <aggi>i did refrain from x86 as a priority, due to the closed-source hardware nature of it; however ao486 at least does provide a proof-of-concept open-hardware is available with x86 <aggi>and this isn't that much better or worse than any ARM/RISC-V whatever anyway <aggi>chances are, a self-hosting/bootstrappable system is possible with linux-2.4(x86)/tcc-toolchain/toybox <aggi>too, linux-kernel build was already verified with kernel-2.4, hence this spares me alot of effort to repair kernel-5.10 i currently blocked at (C11 trouble) <aggi>tcc-toolchain is known to support linux-2.4/x86 <aggi>furthermore, on x86 the blocker at uboot-loader (python3/libffi not passing with tcc-toolchain) is void <aggi>and, the firmware situation, as a proof-of-concept, with an ao486 SoC isn't that bad either (some bochs/seabios) <aggi>ao486 and x86 in general got many problems, however, any ARM/RISC-V/whatever, in practice, aren't any better or worse <aggi>regardless of what the marketing spam mills from sillicon valley excrete <aggi>and x86/linux-2.4(2.6) got another huge advantage: stability, known to compile with tcc-toolchain <aggi>i had that many issues with linux 4.4/5.10 etc. and various aarch32/64 systems, i am not willing to waste my time with this <aggi>anyway, to verify this approach, this is the next milestone: mes-libc+toybox <aggi>compiled/linked with tcc-toolchain _only_; no gcc, no binutils, no autotools, none of this <aggi>and somehow retain a self-hosting system which can bootstrap/compile itself; i think it is possible <aggi>if, mes-libc/toybox etc pass with tcc-toolchain, and if linux-kernel pass with tcc-toolchain <aggi>and for this, i am willing, to roll-back to linux-2.4 <Hagfish>yeah, i think those are valid and achievable goals <Hagfish>you don't want to do too many epic impossible things at once, or you'll not leave any challenges for future generations :) <stikonas[m]>fossy, doras: maybe then it makes sense to postpone dynamic linking until after newer GCC (10 or so). Then we don't need any patches <stikonas[m]>Though if autogen is going to be bootstrapped by mihi, I would prefer to put newer GCC after autogen <fossy>yep, autogen really should go as early as possible if autogen can be bootstraped <fossy>rather impressive mihi is working on it as well, it's an absolute mess <stikonas[m]>Or we need to add g++ to 4.0.4 but I think former is ok <muurkha>well, I suppose that edumb wouldn't be very usable in 512 bytes of memory :) <doras>stikonas: I guess we can always drop the patches if/when we decide to remove support for dynamic linking in that stage of the bootstrap. It would be a shame to postpone this feature until we get a newer GCC going. <mihi>I've eliminated the remaining generated files from https://github.com/schierlm/gnu-autogen-bootstrapping and did not find any more ones during the process. Yet before announcing it to be completed, I'd love if anyone of you could double-check if I missed some obvious generated files. Tarball mode is also there now, but it needs a bunch of files from the git repository as well as they are not <mihi>included in the tarball. <mihi>(I also removed the wip branch and squashed it to become the new main branch) <stikonas[m]>doras: no need to postpone, we can merge them soon and later move dynamic support after newer GCC <doras>stikonas: sure. I'm doing a final round of bootstraps for both PRs after handling the review comments. <stikonas>readelf -a does contain 45: 00000000 0 NOTYPE GLOBAL DEFAULT UND u8_check <stikonas>oh, that was because I was missing --static in pkg-config flags <stikonas>I still have some failures but I did get to stage1 autogen binary <stikonas>fossy, mihi: the good news is that stage1 autogen is already enough to bootstrap gcc's Makefile.in <stikonas>even if I still have some issues with further autogen bootstrap steps <mihi>stikonas, about your mk-opt-table-error: Do you have a chance to look at the generated autogen input file? It is built with sed from the script and some long egrep command, and I am not 100% sure that old sed/egrep will build that properly. <stikonas>mihi: I can take a look, but might be tomorrow <stikonas>I've exited that live-bootstrap session... <mihi>Another idea might be to run the same file through a statically linked non-bootstrapped autogen, the original defparse has "slightly" better error reporting than the bootstrapped stage1. <stikonas>I started it, hopefully it finishes before I go to bed <stikonas>mihi: and how do you think we should deal with pkg-config flags? <mihi>but my assumption is that when you look at the file, something is already messed up so far that it is no valid Autogen file any more. <mihi>to be honest, I don't have experience with pkg-config and the flags I used were mainly trial and error (tested on Linux and cygwin) <stikonas>mihi: I guess we want to support both statically and dynamically linked guile? <stikonas>well, I don't have much experience either <stikonas>but it seems like your flags only work if guile is build dynamically <mihi>I'd like it to work with stock debian packages (guile-2.2 and guile-3.0), and of course in live-bootstrap. <mihi>feel free to introduce one or two more shell variables for that :) <stikonas>or try to check if static build works, if not try dynamic <stikonas>though I might need to setup some other build environment for that <stikonas>right now I don't have guile-3.0 on my system (only guile-2.2) <stikonas>and live-bootstrap does not yet support dynamic linking <stikonas>anyway, I'll still have to check for pregenerated files... <stikonas>today I was mostly trying to get it running in live-bootstrap <mihi>at which point is the linkage failing? already when you are building the getGuileVersion binary (which only needs header files)? <mihi>or later when linking "the real thing"? <mihi>if the latter, it may be a good idea to try with a smaller binary first (similar to how Autoconf works). <mihi>but I think, shell variables should also work fine. <stikonas>mihi: no, when I'm linking autogen (that last gcc command) <mihi>I probably won't be awake in 2h anyway, so if you prefer me to do some live debugging, we'd have to do that tomorrow evening. <mihi>otherwise if you just want to poke at it, feel free to do so :) <stikonas>ok, let's do tomorrow evening, I can try to poke a bit <stikonas>as for flags, my temporary workaround was $(pkg-config guile-3.0 --libs) -> $(pkg-config guile-3.0 --libs --static) <stikonas>but I think that will break bootstrap if there is no guile with static-libs <stikonas>anyway, that's solvable issue and shouldn't be too hard <mihi>and a few lines above is the sed command that builds the temp file, from parts of the script starting at line 131 <stikonas>and at some point later I still need to backport fixes to bootstrap-tarball.sh script... <mihi>if you don't find time, no big deal, bootstrapping can wait :) <stikonas>yeah, in any case, impressive work as always <mihi>your PR succeeded on the GitHub workers, merged :) <stikonas>well, HAVE_UINTMAX_T was the only slightly risky change, the others were quite safe <mihi>where Guile was more about thinking how, then the actual implementation was done rather fast. Autogen was more like lots of small hurdles and lots of trial&error until I got to the point where stage1 autogen could actually bootstrap the whole thing. <stikonas>in any case, stage1 autogen is good enough for gcc <mihi>at least the version you are currently bootstrapping :) <mihi>and in case it is really some sed/egrep issue, maybe you later have more recent versions of it and it can bootstrap the whole thing. <mihi>or patch the scripts, of course :) <stikonas>though at least they are now build with musl and not meslibc, so far less buggy <mihi>maybe run the bootstrap on your machine (outside live-bootstrap) to that point so you have a file to compare to :) <stikonas>I can, though I need to install guile-3.0 <mihi>guile-2.2 should work as well if you change the pkg-config calls <stikonas>otherrwise I get ../../../getGuileVersion.c:13:10: fatal error: libguile/version.h: File does not exist <mihi>maybe, I only tested it on Debian derivatives so far. <stikonas>well, I could try to see what's going wrong on Gentoo too <mihi>"pkg-config guile-3.0 --cflags" and/or "pkg-config guile-2.0 --cflags" work for you and include the includepath? <mihi>anyway, see you all tomorrow :) <stikonas>I think $(pkg-config guile-3.0 --cflags) <mihi>yeah, that may be. So time for another shell variable :) <oriansj>although going through my old emails to pick out the bootstrappable mailing list, there are a few good emails that weren't sent to any lists that might be useful historical perspective