IRC channel logs

<aggi>ok, it's been only a handfull of builds that were hit by AR=ar (and no other binutils utility), which was easily fixed

<aggi>this only leaves perlcross-5.36 remaining locked against elfutils-readelf (which too can be fixed by manually defining target type sizes)

<aggi>which means tcc-toolchain support is complete and confirmed

<aggi>for linux-tcc kernel (and maybe tccboot) build that leaves only a hundred lines of 16bit x86 assembly locked against binutils-as

<aggi>with regards to a tccboot/JiT approach, this could be integrated into live-bootstrap early (as soon as mes-cc i think could compile this plus an assembler to digest the boot code)

<aggi>by default tccboot can handle romfs to place linux-tcc kernel sources into, for JiT compile of kernel during boot

<aggi>however, this approach did not yet consider a JiT compile of busybox with a tcc-toolchain to spawn a shell with compiler available

<aggi>i think there is a few limitations with any approach, related to build-time circular dependencies

<aggi>if i am not mistaken, not sure if the live-bootstrap tcc-build (or the tccboot one i kept in mind) already does/would need a musl-libc and/or fiwix-kernel

<aggi>and unrelated to this, in principle live-bootstrap itself is spawn on a development host with python involved (although that's merely a pragmatic approach easily justified to do so, it does imply a circular dependency)

<aggi>and i recall the argument, creating and transferring any root.ext2fs was problematic in this regard too

<aggi>next i'll try to hack the linux-tcc bootcode.S pieces for support with as86 and/or yasm/nasm

<aggi>then, i'll try to get going live-bootstrap up until the point where it got a fully functional musl/tinycc available, and from there re-integrate pieces of my TinyCC/OS fork, without coreutils/binutils/gcc/linux-4.x and a busybox/tinycc/linux-2.4 instead

<aggi>which got another benefit, since i considered a separate minified TinyCC/OS variant for release (without mplayer/ffmpeg/tetex, 500builds since this is of no interest to neither tinycc-devel nor bootstrappable)

<aggi>such a minified fully bootstrappable tinycc/os release will be much smaller hence easier to cope with for release (instead of pushing gigabites of git-repos, distfiles and a big portage-tree fork)

<aggi>*gigabytes

<aggi>atop of such a minified tinycc/linux2/os release the gentoo-portage/tcc fork bootstrap will be re-confirmed - at this point that's all optional to proceed with anything desired (portage,gcc,llvm)

<aggi>ideally i could keep autotools/perl optional for separate bootstrapping of those with a minified release too

IRC channel logs

2026-02-25.log