IRC channel logs

2024-06-19.log

back to list of logs

<pabs3>SWH and ArchiveTeam Codearchiver haven't archived darcs.haskell.org, no darcs support
<aggi>seems there was some refactoring here: https://github.com/fosslinux/live-bootstrap/tree/master/sysa/
<aggi>found it already, git commit 6ed2e09f3a533a1efdd807a77a7c00a07bf984f1
<aggi>looking for the musl patches, not sure, if i wouldn't want to try newlib instead (that's the one fiwix.org chose)
<aggi>seems live-bootstrap uses musl-1.1 with tcc (without binutils/gcc required?), and then later musl-1.2 with gcc/binutils
<matrix_bridge><Andrius Štikonas> Newlib needs autotools
<matrix_bridge><Andrius Štikonas> Which is why musl was more appropriate for live-bootstrap before autotools is bootstrapped
<aggi>yes, amost everything does... but the fork towards oasis-linux style system integration with lua is too far ahead
<aggi>too quickly checked $ ls python perl of live-bootstrap... scary
<aggi>because, for the mentioned stage0-x86-tcc i am residing on an unverified/compromised BUILDHOST still (spawn from gentoo), that i want to replace with #bootstrappable some time
<matrix_bridge><Andrius Štikonas> Well, we also managed to build gentoo off live-bootstrap
<aggi>for #gentoo i would need python, for autoototols i would need at least perl-5.8.6 (that's the one i verified here compatible with autotools_
<aggi>stikonas: good!
<aggi>however, the acceptance criteria i consider, are a little more strict (no gcc, no binutils as long as possible for the entire stage0 userspace)
<aggi>this one for musl seems a little scary: musl-1.1.24/patches/fenv.patch
<aggi>because this would break floating point exception handling, and i intend to use the system (designated as stage0), as a self-sufficient development host, instead of bootstrapping "only"
<aggi>hence i fear to end up with a slightly broken libc (musl document problems with threading for <linux-2.6 too, besides FPE handling)
<matrix_bridge><Andrius Štikonas> aggi: for fenv feel free to add those assembly instructions to tcc
<matrix_bridge><Andrius Štikonas> That shouldn't be too hard
<matrix_bridge><Andrius Štikonas> ekaitz did a lot for riscv
<aggi>i am having no problems with admitting i am not sufficiently competent to accomplish this within a reasonable time-frame
<aggi>and another issue seems to be, with the proposed system-integration path of mine, that's a fork against live-bootstrap with yet unknown efforts required to keep that compatible
<aggi>such as live-bootstrap step1 (in current terms) -> your tcc-version/musl-1.x -> verified/clean BUILDHOST for my stage0
<aggi>and i rather avoided python completely (not an absolute criteria, but ls python seems scary to me), hence various scripting of #bootstrappable will be gone for me
<aggi>re-calling the issue of the kernel-bootstrapping i verified, how BUILDHOST was poisoning/leaking i386-tcc cross-compiler, that i had to move onto slackware11 temporarily for testing
<aggi>hence, your bootstrapping work providing a verified/clean buildhost is crucial
<aggi>with regards to RISC-V, i am worried it won't be possible to kernel-bootstrap with tcc-toolchain, and instead various intermediate steps (fiwix etc) are required, to arrive at gcc/binutils cross-compilers for kernel capable to run on any risc-v hardware
<aggi>just in case it was supposed to be a linux-kernel (5.x, 6.x) for risc-v one day, it's an equivalent for gcc -S missing required by Kbuild ever since linux-2.5
<aggi>susematz failed with linux-4.6 verified against tcc-toolchain (ignoring the 16bit real-mode assembly parts)
<aggi>that's TWO giant blockers for kernel-bootstrapping when keeping tcc-toolchain, if risc-v couldn't be powered by a linux-2.x (and it can't)
<aggi>and risc-v will imply an additional cross-compilation stage, due to this, except if #bootstrappable considered a complete re-integration for risc-v
<oriansj>aggi: well it is possible to backport RISC-V support to older Linux kernels if you wish to achieve TCC-only Linux bootstrap.
<oriansj>(on RISC-V of course)
<aggi>oriansj: there seems no way around x86 anyway, hence the question too is if the x86 path should remain when heading towards RISC-V
<aggi>i wouldn't expect this to be a realistic scenario
<aggi>because i was trapped and mis-guided by aarch64 once already, and a relevant criteria for this: long term supply of desirable hardware
<aggi>if an operating-system/firmware was tailored for any board (including u-boot and a kernel patched whichever versions that would be, 5.x/6.x mainly nowadays)
<aggi>few years later various development SBC aren't available anylonger
<aggi>i think risc-v will be affected by this problem too
<aggi>in comparison, i could throw a x86-[gcc4|tcc]-linux.iso at almost any hardware, although uefi could complicate this in the future
<aggi>i am not in the mood to fiddle together customized os-firmware images for dozens of different variants and vendors, which is the situation of ARM currently, and risc-v following
<aggi>and if a clean bootstrapping towards an alternative ISA was desired, this involved x86 as a buildhost with cross-compilers anyway
<moikvin>does anyone have to link to that one repo with the great readme about how each step(starting with hex0) works?
<oriansj>moikvin: https://github.com/fosslinux/live-bootstrap/blob/master/parts.rst
<oriansj>aggi: fair enough concern about ARM and RISC-V; they lack any core platform where they are strongly tied to for compatibility (unlike IBM 390X or x86 or AMD64)
<oriansj>PowerPC is kinda iffy
<matrix_bridge><cosinusoidally> In theory with things like devicetree ARM/RISC-V may eventually catch up to the x86 PC circa 1994 where you have a standardised way of booting, and can use the same generic kernel on all machines. Looking back at Linux distros it seems to have been about ~20 years ago where they started getting generic kernels that could be used on every PC. I guess that was more to do with struggling to fit the...
<matrix_bridge>... kernel onto a floppy rather than any technical limitation of the PC platform though.
<matrix_bridge><cosinusoidally> (looking at slackware I mean)