IRC channel logs
2025-12-29.log
back to list of logs
<aggi>sortie: thanks again for the perl.static/cross hint, it's been an important piece missing for a while <sortie>Honestly it took a long while for me to get perl working properly, due to their insistence on the weirdest unexpected build system, so I'm really happy to share my insights and patches :) <sortie>Better cross-compilation and static linking generally helps everyone and bootstrapping is definitely an important use <aggi>this is the idea, to retain a fully tinycc-driven system, statically linked <aggi>which can be both fully cross-compiled and/or be spawn from bootstrappable <aggi>then itself being used as _comfortable_ buildhost to spawn any other system <sortie>I definitely need to do a full bootstrap from stage0 at some point. I wrote my entire own OS, and it can be bootstrapped (cross-compiled) from a C++ gcc GNU-esque world easily, and I test that every night. It could be fun to link that up to the boostrap of a C++ world, that problem is super solved by now <aggi>that's another aspect, once the bootstrapping from stage0->tinycc/linux system was re-confirmed <aggi>then it's mainly the transition from tcc->gcc/g++ to bother with remaining almost always <aggi>and that's much easier done with some bootable linux2/tinycc ISO instead of hours and days compile-time <aggi>i've not re-confirmed the stage0 procedure myself yet, and trust live-bootstrap is readily available to do so, which it is <aggi>and i want to move my main development host back onto linux-2.4/tcc, which currently seems only blocked by some instability bug inside a backported usb-ethernet dongle <aggi>because, besides qemu/virtualbox, tinycc/linux is intended to run on bare-metal hardware easily, that's a main reason linux2 was worth a little effort <nikolar>the hardware compatibility is limited though i imagine <aggi>for this, ethernet is important, and i can't nor won't backport dozens of different ethernet chips <aggi>well, the AX8872 rev a/b/c does work already, but it's hit by some instability bug with large packets sent - i'll debug this again <aggi>with regards to SATA/IDE, inside virtual box sata and ide ports are detected by ahci and libata, on some old thinkpad t40 libata detects the ide ports <aggi>on some newer hp t620 thin client i have to check again, why sata ports aren't detected (linux2.4 had different drivers) <aggi>at minimum i want to see sata ports detected _always_ with the IDE-compatibility mode <aggi>usb2-flash/cdrom is detected always already <aggi>vesa-framebuffer high-resolution, FullHD did test OK too, which needs the mode passed at kernel command line, it's just not auto-detected <aggi>the old t40 thinkpad is supported just fine by linux-2.4: audio, onboard ethernet, ide <aggi>usb-audio class should work, i've just no device to test with currently <aggi>i want to backport some cheapo ush-hdmi grabber too, it's sufficient to grab some dvb-t2 stream with ffmpeg/mplayer onto framebuffer-terminal <aggi>WiFi/WLAN is a challenge, rtl8188(eu) would be desirable, but it's notable efforts and can't be used easily blobless <aggi>most important, it's cleaning up chaos inside the userspace-fork, to git-push this <aggi>ideally it's had a tad more runtime testing other than self-hosting re-compilation <sh4>aggi: ftr, dalias, the author of musl considers 2.6.30 to be the baseline that's sufficiently "modern" to support all of musl's features correctly, most importantly threading <sh4>2.4.x is likely pretty broken in that regard