IRC channel logs
2024-10-25.log
back to list of logs
<aggi>i did check live-bootstrap tree for perl too, but i keep ~500ebuilds in maintenance here and ocassionally missed one or another spot <aggi>seems the python-3.8.16 pass1.sh bothers with lib-dynload, which wouldn't be supported by tcc/static, besides tcc-assembler couldn't digest some mnemonics that python uses <aggi>thing is, i'm less concerned about python/portage, that's not too challenging, but i scripted my whole workflow around gentoo crossdev <aggi>and that's one i will be missing <aggi>my focus is a full transition towards a tcc-toolchain only system (plus binutils required for 16bit real-mode asm) <aggi>and this one is x86-exclusive anyway <aggi>even when risc-v progress is made with tcc, i don't see a chance to compile any recent linux-5.x/6.x kernel version with tcc ever that risc-v would need <aggi>hence the python/portage/crossdev issue isn't critical, since there isn't any supported target other than x86 to transition to anyway <aggi>however, maybe the best approach would be, to spawn the full live-bootstrap seeding from i486-tcc-linux-musl.iso <aggi>and reastablishing a gentoo-crossdev atop of that, with a verified/clean bootstrapping process for it <aggi>because i don't want to loose the flexibility to transition to arm/risc whatever, and this is what crossdev is good at <aggi>so, i'll get perl with tcc/statick back on board this week, since it is known-good among #bootstrappable i can trust <aggi>and then, back to kernel+tcc, the linux-2.4 hackjob, don't know yet if musl-libc interacts with this kernel version <aggi>another question: to my knowledge a gentoo/portage bootstrap was feasible with live-bootstrap <daddy>stikonas: interesting, we had a dead mirror in stagex for openssl 1.1.1. <aggi>however, i haven't got python itself with tcc/static-linking, and live-bootstrap relies upon python <daddy>going to openssl.org points to openssl-libary.org which points to github archives <aggi>python is problematic (cross-compilation, static linking, tcc), it's not a showstopper such as perl/autotools would have been <aggi>gladly there seems not much that is written in python for live-bootstrap <aggi>as far as libre/openssl are concerned, i did a test-run against wolfssl last week, but this can't avoid the ssl.h api related issues <aggi>as soon as there's an #include <ssl.h> fun begins, with any libre/open/wolfssl, but this is what most pkgs need <aggi>bearssl is much easier to handle, but it doesn't implement the entire ssl.h api, that's why it's much simpler <aggi>but i don't see a realistic chance to avoid ssl.h, although curl supports bearssl for example, there's several dozen other pkgs that would need extensive re-write for a clean tls api/library such as bearssl <aggi>so far this question is answered, i'll have to avoid python when focussing on the tcc/static system-profile <aggi>python can be bootstrapped, but it's not self-hosting with tcc/static itself, ok. <aggi>so, the most realistic approach to spawn i486-tcc-linux-musl.iso atop/with live-bootstrap is re-writing the python-scripting (rootfs.py) <aggi>the biggest show-stopper is linux-2.x/tcc still <stikonas>as for building python with gcc, I don't have much insight here... <stikonas>haven't tried for more than a few minutes <stikonas>and python really needs dynamic linking for some stuff <aggi>README.rst "Without using Python", well, ok. <aggi>to my understanding this part is sufficiently stable and completed by #bootstrappable <aggi>and it's an almost trivial fork to stop at a working tcc-toolchain emitted; so i can skip the gcc related parts completely, and proceed with my i486-tcc_static-linux-musl.iso scripting <aggi>this however, i have to rewrite, because i did the whole tracking with gentoo-crossdev and python is gone indefinitely <aggi>then this yields a BUILDHOST with tcc, and this one can bootstrapp gcc/binutils/python/crossdev towards any desireable target <aggi>except a bootable linux-2.x/tcc kernel (or any later although i have doubts this is feasible, others failed before) <aggi>fyi, i just did git-commit and tag tcc-toolchain for the complete set of ~500 ebuilds i was tracking, i already got a root.squashfs for this <aggi>but i can't boot this with a kernel that compiled/linked with tcc, not yet <aggi>that's two big tasks remaining mainly for me: 1) rewriting the crossdev/portage scripting, that's not an all at once so i can do this gradually for those ~500 ebuilds beginning with crucial development utils, even gdb-7.12 compiled/linked with tcc seems to work now, since the cmp $0 patch was applied <aggi>and 2) thats a total show-stopper currently, linux-2.x/tcc <aggi>if and once this is completed, there's a candidate for a bootstrappable tcc distro <aggi>something which was missing for decades <stikonas>Googulator27: any thoughts about what to do with openssl? <stikonas>we can jus as well download from github... <stikonas>Googulator: shall we switch to distfiles gentoo for now? <stikonas>wolfssl is potentially buildable very early <lanodan>I picked bearssl on my side, at least curl (and so git as well) can use it. <stikonas>though again, does it have http only downloads... <stikonas>maybe it doesn't matter that much, it's much smaller <lanodan>Oh wow yeah, 15M for OpenSSL 3.0.13 (and 18M for 3.3.2) vs 748K for bearssl <deesix>Also around here, for example (they keep all) snapshot.debian.org/archive/debian/20240325T091329Z/pool/main/o/openssl/openssl_3.0.13.orig.tar.gz <lanodan>Oh yeah snapshot.debian.org is probably a good idea <deesix>Not downloading would be better ;)