IRC channel logs
2024-08-13.log
back to list of logs
<aggi>>>> Installing (1 of 2) app-cdr/cdrtools-3.02_alpha09-r4::hotfix to /usr/i486-tcc-linux-musl/ <aggi>that's all completely statically compiled/linked with tcc-toolchain <aggi>currently i am forced to static-linking _only_; that's a problem with perl still <aggi>because perl needs to load DSOs for various modules that autoconf/automake need <aggi>however, if i can repair this, static linking of perl with the necessary objects, then i can salvage GNU buildsystem to remain self-hosting with tcc-toolchain <aggi>full static linking support is/was a nasty hackjob, and some things don't work yet (gdb, python/gentoo-portage) <aggi>i got linux-kernel on TODO still, tcc-compiled kernel segfaulted (but i could reproduce a known-working state already, to bisect what went wrong) <aggi>bootstrapping binutils with tcc worked (gladly, because kernel bootcode needs 16 asm), gcc-4.7 didn't compile with tcc yet <aggi>conclusio: it is feasible to utilize tcc-toolchain as system compiler _only_, currently with static-linking <aggi>next i'll try to salvage perl for static linking, since i cannot quickly repair dynamic linking support with tcc-toolchain/musl libc.so <aggi>btw.; i had to patch tcc a little, to sanitize include and library search paths when cross-compiling <aggi>mutt mailer, ffmpeg, mplayer... all of it fully supported now, with tcc and static-linking <aggi>i havent got GNU autoreconf support yet, because perl <aggi>python neither, and there is another coincidence with both of them, perl and pythong <aggi>since i patched kernel, to enforce W^X policies, and there is only two W^X policy violators remaining, perl and python <aggi>to my understanding, this opens a security loophole, if PROT_READ|WRITE|EXECUTABLE is allocated <aggi>however, to avoid this, i had to re/write 500 Makefiles of the ebuilds that i kept passing the no-c++/tcc/static criteria <aggi>to avoid the "pre-generated" GNU configure/makefile, and that's too much <matrix_bridge><cosinusoidally> The pnut C to posix shell compiler posted the other day looks interesting. It's quite slow to bootstrap (a couple of mins for me) but it does also have an i386 backend. In the readme it does claim to be able to compile tcc, but I couldn't figure out how to do that. I raised an issue with them https://github.com/udem-dlteam/pnut/issues/63 <matrix_bridge><cosinusoidally> It also does not seem to work with very old versions of bash. I also had trouble trying to run it under the busybox shell. I think in theory ksh will build it, but again it needs to be a new enough version. <matrix_bridge><cosinusoidally> Still could be useful as a diverse bootstrap path (eg it probably can compile M2) <matrix_bridge><cosinusoidally> Some shells will fail part way through the bootstrap (with the bulk of the outputted code looking ok, but just truncated) <aggi>shell plus a few userspace utilities <matrix_bridge><cosinusoidally> and still you need a C compiler to compile pnut.c to pnut.sh . Once possible way around this would be to ship a manually tidied up version of pnut.sh <matrix_bridge><cosinusoidally> aggi: yep I don't think they are too clear about which utilities. <matrix_bridge><cosinusoidally> It does bootstrap under the slackware 15 mini installer iso (which contains bash/busybox) <aggi>no clue, why they would transpile c-to-shell <aggi>i was worried, which userspace utilities would remain, when enforcing tcc <aggi>since recently i got statically linked with tcc: coreutils, util-linux, bash, oksh, and toybox <aggi>perl and autotools are missing, because perl <aggi>it's build-system isn't prepared for static linking, that's needed to load various modules that automake/autoreconf need <aggi>it's a deadlock/trap, into various directions <aggi>current situation, if, and only if, i manage to repair perl build-system, then there simply is no need to bootstrap gcc and/or support for dynamic linking <aggi>in any case, perl will violate W^X policies enforced by kernel <aggi>i can live with abandoning python/gentoo-portage, although i don't intend to, because it implies a re-integration of ~500 ebuilds <matrix_bridge><cosinusoidally> aggi: from the readme "As a way to bootstrap a compiler written in C with an executable version that is still human readable" <matrix_bridge><Andrius Štikonas> cosinusoidally: but as you said, you still need C compiler to bootstrap pnut... <matrix_bridge><Andrius Štikonas> and I guess transpiled C -> shell code looks even worse than autoconf scripts... <lanodan>Well the idea is probably more to distribute the resulting shell code as a seed. <matrix_bridge><Andrius Štikonas> perhaps, but I still think the proper way is to start with smaller compilers and eventually assembler <matrix_bridge><cosinusoidally> Andrius Štikonas: the generated output isn't actually that bad. It could be tidied up and frozen into a "pnut_bootstrap.sh" file that never changes <matrix_bridge><Andrius Štikonas> if you start from shell, there is still implicit C compiler somewhere that was used to build shell <matrix_bridge><cosinusoidally> yep, but it does give you an additional diverse bootstrap path that works on Linux machines without an existing toolchain.