IRC channel logs
2024-11-01.log
back to list of logs
<aggi>fyi, as an intermediate solution for perl/autotools support with tcc/static-linking <aggi>1) i'll leave the perl-5.6 hackjob to bootstrappable trusting that one is stable once needed <aggi>2) approaching from the gentoo/ebuild side i hacked into perl-5.8.6 to add necessary extensions into a statically linked perl (that ignores various bootstrappable criteria to re-generate headers etc.) <aggi> this build just succeeded and i can test autotools/automake support is functional again (which it probably is :) <aggi>3) once converging and re-integrating the tcc/static system profile towards bootstrappable i can utilize the fully sanitized perl-5.6 instead <aggi>so far so good... however... perl-compilation remains a significant issue, which raises the principle question over utilizing autotools/automake <aggi>the good news is, since perl/autotools support is available, re-writing affected ebuilds/makefiles can be done gradually, one by one, until autotools and perl can be removed entirely <aggi>the concerning aspect with those, it's the mandatory presence, perl/autotools aren't optional <aggi>since the tcc-profile of mine doesn't need gcc (and a few other trouble sources), some crucial builds already were re-integrated <aggi>for example binutils,libressl,netbsd-curses at oasis-linux side, and gcc makefile.am don't need a re-write since gcc isn't necessary <aggi>hence an i486-tcc_static-linux-musl.iso can be emitted, with a little less hazzle than being forced into gcc/perl mandatory dependencies <aggi>i'll get back to linux-2.4/tcc soon (depending on non-technical circuumstances) <aggi>some idea surrounding i486-tcc_static-linux-musl.iso: <aggi>a notable amount of troublesome pkgs could be excluded from bootstrappable/steps/, if autotools/perl/gcc can be avoided with a tcc-only system profile <aggi>then, instead, a bootable iso built upon a trusted bootstrapping path was available, and re-establishing the full GNU system-integration tooling could be done comfortably with regular LFS style scripting <aggi>i am digging into live-bootstrap currently, seeing to how my system profile can be converged and re-integrated with it <aggi>since i am having trouble with python for example, that i used with portage/crossdev for tracking the tcc system profile <aggi>i have to re-write the system-integration/packaging anyway, and i'll try to move as much as possible into the bootstrappable steps scripting <aggi>the problem i see with bison/perl/gcc, currently those are required rather early in the bootstrapping path <aggi>which too is related to the unresolved issue of kernel-bootstrapping (i could reproduce some minimals tccboot/kernel-2.4 while ago, without the need for gcc/perl/bison/...) <aggi>anyway, i'll have to stay on the gentoo/crossdev side for a little while longer <aggi>although i got a root.squashfs for i486-tcc_static-linux-musl.iso already, i can't compile and boot any kernel yet that fully passes with tcc <aggi>otherwise i don't see a showstopper, to converge and re-integrate the tcc system-profile with bootstrappable <aggi>even binutils was shown it can be re-integrated, without perl/autotools even, as oasis-linux did <aggi>since that's needed for 16bit real-mode assembly boot-code of kernel <aggi>although i would prefer a linux-2.4 for example, there could even be a chance to hack any later version (Kbuild changes since v2.5, gcc -S, linker-script support) <aggi>for linux-2.4, there would be three options: 1) JIT with tccboot, 2) AoT-compile with tcc-only, 3) AoT-compile with tcc, linking and 16bit asm with binutils <aggi>with later kernel version, only AoT compile is feasible, with the need to keep some pre-generated files (gcc -S inside Kbuild), i could live with it <aggi>the intermediate Fiwix boot isn't critical, since it's supported already with tcc, and isn't a hindrance to any linux-kernel proceeded with <aggi>your work is extraordinarily important <aggi>it's just, for example, i think perl/autotools aren't worth an order of merit, it's a huge burden to bootstrapping and system-integration <aggi>it's good i got that back on board with tcc-static, hence i can gradually re-write the packaging and makefiles to avoid it, instead of doing it all-at-once as an all-or-nothing task <aggi>since i got ~500 ebuilds on maintenance inside an overlay here, most of which i would want to keep <aggi>fyi, i got monstrosities such as gdb, ffmpeg/mplayer, mutt mailer, links/lynx, irc on board, all passing against no-c++ tracking and compiled/linked with tcc statically <aggi>and i don't see any issue to move this onto bootstrappable scripting <aggi>the benefit of crossdev scripting patched for tcc, i can quickly dependency-track, rebuild the complete system, boot and test it <aggi>i got a rather fast devdrop release-cycle, to assert things work as these should, for re-integration into less flexible steps-scriptiong of bootstrappable <aggi>since i don't need gcc anylonger, compilation time is much faster now, my distro is compiled/linked in ~2hours with i386-tcc (~500ebuilds) <aggi>and this includes somewhat slow python/portage/crossdev, once that's removed on bootstrappable side, the build-time will significantly improve further <aggi>with a tcc/no-c++/no-gcc system-profile, a _complete_ distro such as mentioned, can be emitted quickly, even on low-power x86 thin clients