IRC channel logs
2025-12-23.log
back to list of logs
<fossy>this is the first i'm seeing of mes-replacement <nimaje>"Furthermore it requires the usual Linux commands and the GNU C compiler." wait, how would that help? doesn't mes and tcc come before gcc in your bootstrap chain? <stikonas>fossy, LaurentH: I've heard of it before <stikonas>I never fully understood the point of writing the interpreter that then prints execution graph though... <stikonas>but if somebody wants to double check that, then fine... <aggi>nimaje: there is problems known to transfer some bootable image onto a machine <aggi>otherwise, to my limited knowledge, the bootstrapping chain isn't circular <ekaitz>stikonas: I moved gcc-4 to codeberg, i don't know if you've seen that <stikonas>one of the few things to happen here recently... <stikonas>in general I think people were quite busy recently <LaurentH>stikonas: thanks for the link to the talk, I had missed it <LaurentH>I think they have a good point when they say that there's a lot of moving pieces before getting to TCC. It took me some time to understand how all the hex/M*/mescc-tools fit together <LaurentH>I'm not sure that introducing an intermediate low-level language (C--) solves that problem though, since it still depends on M1 <sh4>i wonder why everyone's so fixated on tcc as opposed to e.g. cproc <sh4>it's probably a lot less effort to support the C subset cproc/qbe are written in than tcc <sh4>oh, it's a probably because tcc has its own assembler/linker already built in, hmm <LaurentH>I think they require a similar effort to support. To get cproc/qbe working, you also need to bootstrap (and write?) assemblers for each target platform <LaurentH>exactly! That argument doesn't hold as much if you're targeting a platform not support by TCC, since adding a new TCC backend require a lot of work, but there's momentum in using it <sh4>tbh i'm not that happy with cproc's choice of backend. it's pretty hard to teach qbe new archs, and 32bit support seems to be entirely lacking atm <sh4>for bootstrapping purposes, a simple bytecode backend could probably be the best choice <sh4>(similar to what lcc does - which is also used for quake3 btw) <LaurentH>hmm, I haven't looked at cproc, but I'm hoping it can be used as an alternative bootstrapping path for GCC <sh4>yeah, it can build gcc 4.7.4 after applying a handful of minimal patches removing gnuc assumptions <LaurentH>You're probably right that a bytecode backend could save a lot of work <sh4>the code of cproc is top-notch, it builds in less than a second even when using gcc to bootstrap it <sh4>you type make and it finishes almost instantly <LaurentH>I should try to compile it with pnut to see how far we are from bootstrapping cproc <LaurentH>I'd like to add support for 64-bit arithmetic on 32-bit hosts in pnut in the next few months, that would make more programs work without patches <aggi>other than it's importance to bootstrapping, TinyCC was the only toolchain it was feasible with to detangle a complete distribution from gcc/llvm <sh4>yeah i saw that. wonder why it no longer works with musl's dynlinker though <sh4>IIRC 4-5 years ago i cloned the mob branch and it worked just fine with musl, whether dynamic or static <aggi>sh4: once musl-libc itself got compiled by tinycc it wasn't working anymore <sh4>at that time tcc couldnt compile musl at all <sh4>too much inline asm and the complex float stuff wasnt supported <aggi>and, of cause any kernel, hence i had to backport musl and userspace back onto a linux-2.4 <sh4>though the latter can be easily disabled by simply deleting the complex float files <aggi>because i wanted a kernel pass compiling/linking with it, tinycc in this case <sh4>that's quite a feat. i wish there was a tag or even better a release <aggi>i'm still cleaning up the chaos inside staged changes to commit <sh4>oh, it's not in the mob branch yet ? <sh4>well, maybe a fork is the saner choice anyway. it doesnt appear the maintainer will ever produce a release <aggi>no, regressions/bugfixes for tinycc are commited to mob already <aggi>but there's hundreds of hacks and patches for the userspace parts (kernel, musl, and 500ebuilds, forked portage etc.) <sh4>you might want to look into the package manager i wrote for sabotage linux <sh4>it's 99% portable shell script <sh4>99% because we need local variables <aggi>interesting, since you mention it, i grabbed NetBSD curses from sabotage linux, because ncurses was troublesome with tinycc <aggi>i can't re-write packaging, not yet, it's just too much work <sh4>you could probably just grab the existing recipes of sabotage for that matter <aggi>i'm not opposed to replace portage/python with something less hostile towards POSIX <aggi>sh4: those sabotage packaging scripts, are these bashism or POSIX? <aggi>ok, i'll keep that in mind <sh4>i often build single apps using the recipes and a musl-cross cross compiler <aggi>but it's alot of work regardless, because i kept the userspace fork portable towards both linux5 and linux2 sysv-abi <aggi>and i do want to keep the cross-compile back-and-forth between aarch32/x86_32/x86_64 <aggi>so, i have to think carefully <sh4>for example if i need tcpdump for mips, i just create a config file with CC=mips-gcc and then CONFIG=./config STATICBUILD=1 butch rebuild tcpdump <aggi>ok, noted, i'll certainly keep sabotage linux packaging in mind <sh4>bashisms are removed from almost all packages. IIRC the only thing that still depends on it is ffmpeg <aggi>in worst case, i got bash-4.1.static tinycc-compiled on board <aggi>and well, ffmpeg, i forked and patched that one too, it's available with tinycc, as is mplayer-1.4