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>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> 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>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 <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. <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>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) <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.