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>:) !
<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
<aggi>time to reboot
<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