IRC channel logs

<aggi>stikonas: seems the MES-replacement pieces are executed inside a chroot instead of atop the stage0-kernel/loader/kernel from rickmasters

<aggi>which, of cause is necessary, for initial testing; and then later to my understanding a native-boot from any bootstrap-seed launches the complete procedure ex-nihilo _without_ a development-host that testing was done with

<aggi>could be the transition from testing inside chroot to qemu/native is mostly transparent

<aggi>builder-hex0 with it's default Makefile desires QEMU - i see, that's the one i did not yet succeed with backporting to TinyCC/OS

<aggi>but ok

<aggi>i think i'll skip the QEMU/NATIVE first, and take the chroot path first

<aggi>seeing to the whole compile-time and run-time dependency chain is confirmed to arrive at linux-tcc/busybox/linux-2.4-kernel

<aggi>thing is, executing some shell-scripts inside a chroot isn't the challenge here

<aggi>but to grasp the whole picture of it inside dozens of READMEs

<aggi>one approach to keep things in order mentally, distinguishing build-time and run-time dependencies

<aggi>and which circular-dependency any might introduce

<aggi>for that matter, this did NOT yet pass run-time testing with TinyCC/OS

<aggi> https://lists.nongnu.org/archive/html/tinycc-devel/2026-02/msg00023.html

<aggi>QEMU (userspace) and/or KVM (kernel-side) are problematic, regardless of any cirular dependency with those

<aggi>since linux-tcc does shrink the dependency graph by who knows a hundred million lines of code, QEMU cannot yet be used with it

<aggi>gladly QEMU is fully optional, and/or it can be spawn on a heavyweight modern *Nix/Windoze host

<aggi>another reasoning to keep things in order mentally: to distinguish HOW bootstrapping was accomplished (with builder-hex0,stage0,MES,live-bootstrap) from WHAT is being bootstrapped (the bootstrapping TARGET)

<aggi>and restricting the latter to some non-GCC/non-binutils/non-perl/non-python to arrive at a fully capable development host impacts the former

<aggi>of cause i won't manage to zip TinyCC/OS onto a 3.5inch Floppy-Disk anymore nowadays

<aggi>another thing, i'll try to avoid rootfs.py; for live-bootstrap it's good as it is, but i'm having problems with python itself for other reasons

<aggi>interestingly, the TinyCC/OS (which is my development host here already) python.static backport does not yet work anyway with rootfs.py (although it did suffice for gentoo-portage tooling)

<aggi>have to see, MES-replacement already does some scripting-magic (for chroot) without any python

<aggi>as a rule of thumb, since bootstrappable does rely upon development hosts themselves of cause, it's unavoidable:

<aggi>-> such development host does introduce circular dependencies all over the place itself

<aggi>-> it's desirable at least to shrink the size of such circular dependency graphs

<aggi>-> and here's the proposed rule of thumb: try to avoid any utilities on such a development host when those weren't bootstrapped at the preparational stage when it's used

<aggi>which means, if either QEMU or python cannot have been bootstrapped for use, try not to rely upon such

<aggi>in this regard TinyCC/OS shipping with linux2/busybox/tcc could provide a decent sanity check for what's desirable as development host utility and what isn't

<aggi>that's no criticism of live-bootstrapp, but motivated by limitations implied by tinycc/os used as development host

<aggi>another criteria for the choice of development-host utilities involved: standardization (IEEE,POSIX,ANSI/ISO)

<aggi>it's no coincidence both Perl/autotools and Python are/were troublemakers, since those aren't covereed by standardization

<aggi>of cause, python and perl are a desirable mandatory bootstrapping target, but those should appear as either build-time or run-time dependency as late as possible

<aggi>another guidance to keep mental sanity: to distinguish what belongs and/or is unavoidable to integrate with live-bootstrap to arrive at a fully capable development host

<aggi>of cause, python/perl/gcc/binutils etc. MUST be bootstrapped, but i tend to think it's better done separated from live-bootstrap

<aggi>sigh

<aggi>$ du -cah live-bootstrap-MIRROR # ~1.4GiB

<aggi>this doesn't fit onto 3.5inch floppy nor 640MiB sized CDR ISO

<aggi>i'm having the same issue with TinyCC/OS, although that was fully sanitized from _all_ c++ dependencies, fully removed gcc/binutils

<aggi>this bootable ISO with debugging symbols barely fit into CDR ISO sized medium

<aggi>that's one major reason why i've not published the tcc-portage fork, simply because it's too much

<aggi>so i'll re-integrate tinycc/os now from a bootstrapping chain as minimal as was reasonable/possible to provide a development host

<aggi>"*Currently, there is no way to perform the bootstrap without external preparations! This is a currently unsolved problem.*"

<aggi>i appreciate such honesty alot, and might add for mentioned reasons above it is probably not feasible at all to solve this problem

<aggi>the TinyCC/OS approach too merely seeks damage control, to shrink circular dependency graphs

<aggi>stikonas: has the MES-replacement from Frans been confirmed already?

<aggi>i find the differences between and separation of task1.sh and task3.sh a little confusing still

<aggi>the latter transfers control flow to the 'configurator', to build tcc-0.9.26 somewhat gentoo style for example, the former does it with a simpler kaem script

<aggi>i am not sure yet if at all i would follow along with the configurator in favor of plain kaem scripts instead

<aggi>maybe there's a chance even to skip kexec-fiwix/kexec-linux alltogether with a kernel-bootstrap

<aggi>since some usable tinycc already is available, although i did roll along with HEAD version of it to compile linux2-tcc kernel with Kbuild.sh

<aggi>plus, a busybox

<aggi>that already was ported to tinycc/os

<aggi>then there's another missing piece finally, to make some root.extfs2 bootable with isolinux/syslinux/lilo/grub or whatever

<aggi>i don't know yet, if for example, yasm assembler could be exectued _without_ a fiwix kernel ABI below

<aggi>in this context, any kernel involved, had to be considered as build-time and run-time dependency for bootstrapping procedure itself

<aggi>don't know how far the mini-kernel from rickmasters in conjunction whichever libc there was suffice for yasm, for example

<aggi>otherwise, there is some shell-scripting already to build linux-tcc kernel relatively easy, which can be adapted for kaem

<aggi>the busybox-1.2.2.1 build too could be re-factored into kaem style

<aggi>ah, i see, steps/grub-2.06

<aggi>i am rolling along with sys-boot/syslinux-3.86 here, which for that matter can easily be compiled/linked/assembled with tinycc 100%

<aggi>i see, grub isn't described in parts.rst, that's why i missed that... moment

<aggi>with live-bootstrap, steps/grub is built rather later AFTER gcc-15.x... interesting

<aggi>while syslinux could be built rather early as soon as tinycc was available (except isohybrid/cdrecord/mkisofs, but i could happily live with some extfs2.roots/syslinux)

<aggi>what i have in mind, there is huge potential to simplify live-bootstrap if the TARGET of what is being bootstrapped (not how it's done, that's fine)

<aggi>to arrive at linux2/busybox/tcc/yasm/syslinux - that's bootable and while ago such a thing fit onto floppy-disk (nowadays it doesn't)

<aggi>i too would speculate, since busybox - historically - enjoyed being linked against uclibc, there could be a chance to get this going with any of the minified libc involved with bootstrapping

<aggi>then too, the idea to drop binutils (and to gcc) from the dependency chain pays off, since linux-tcc kernel can be compiled/linked/assembled completely without those

<aggi>i could confirm all three: as86, yasm, and gnu-as to process the little pieces of bootsect.S needed, and of cause CC=tcc as it's name says, linux-tcc

<aggi>so that's the route taken: [builder0/rickmasters/kernel/loader/native | chroot] -> MES-replacement -> linux-tcc/busybox/as86/yasm/syslinux

<aggi>i would consider this good enough as initial develoment host, even when that missed SMP for a moment (depends if yasm can be spawn runtime without fiwix/linux5 abi)

<aggi>then, another question would be, of cause musl-libc will be and must be available at some time, if that's needed to get a bootale extfs2.rootfs with linux2-kernel/busybox etc.

<aggi>that's been the approach of Aboriginal Linux, to do this as small as possible - without bootstrapping involved at that time

<aggi>it seems, tinycc is available _before_ musl, ok.

<aggi>maybe i can accomplish the same for linux-tcc,busybox,syslinux,yasm|as86 - don't intend to exaggerate, but this should suffice almost as a bootstrapping target

<aggi>for a sufficiently complete development host to get going all else later (outside the scope of bootstrapping)

<aggi>tcc 0.9.27 (musl v2) -> "Now that we have a fixed ``musl``, we now recompile ``tcc`` as ``tcc`` uses floats extensively."

<aggi>seems tcc is re/compiled 5times with live-bootstrap due to this (two times _before_ musl, and three times after musl)

<aggi>i see, and it is the tcc-musl with floats (not sure of all implications this has) which of cause does need some fiwix/linux syscall ABI

<aggi>seems tcc is re-compiled more than 5 times even, there's some internal ones inside kaem-scripts not exposed as individual step, have to see

<aggi>not sure yet how this differs between GNU mes and MES-replacement

<aggi>to avoid another mis-understanding, i consider fiwix a precious kernel option

<aggi>but i got a little headache when thinking of the kexec-fiwix and kexec-linux involved with current live-bootstrap

<aggi>in conjunction with the musl/tcc issue outlined

<aggi>the kexec-fiwix and re-compiling tcc/musl several times may not be avoidable, but i think the kexec-linux can be avoided

<aggi>i think the reasoning of live-bootstrap was/is a full GNU toolchain latest greatest version instantly available, without some intermediate bootable linux-floppy.img before

IRC channel logs

2026-03-01.log