IRC channel logs
2026-03-10.log
back to list of logs
<aggi>it's too a starting point to kick-start some CI setup for tinycc-devel <aggi>for this i'll try to integrate latest HEAD of tinycc mob branch next, which i'm using for linux-tcc kernel and TinyCC/OS system profile already <aggi>i want to track all steps and distfiles individually (since i've accumulated another distfiles folder on my own too), to shrink that a little <aggi>alltogether this too should help with tinycc-devel to reproduce some issues i've had if a small bundle with all scripting ready is available <aggi>(there is known issues remaining with tinycc which raise concerns even when a complete tinycc/os is up and running here) <aggi>and well, tcc-0.9.27 hash matched when spawn from pnut, so there is a known good baseline <aggi>i'll probably keep steps/tcc-0.9.27/pass1.kaem as is hence, and move all else into steps/tcc-head/ <aggi>steps/tcc-0.9.26, this does pull a distfile which got patched already by janneke, then pass1.kaem applies some, and then a few for pnut <aggi>ok, this complicates re-basing necessary at that stage if live-bootstrap was used for CI nightly-build for tinycc-devel <aggi>steps/tcc-0.9.27, thats 5 passes, pass1.kaem applying simple-patches, and all other applying the _same_ patches/ i guess <aggi>good so far; except for one question what's the reason been patches for tcc-0.9.26 weren't rebased onto tcc-0.9.27? <aggi>it's probably been confirmed as a working setup and kept as is, or was there any other technical reasons which blocked at initial tcc-0.9.26? <aggi>"An examplary case for C-standard de-stabilization affecting entire toolchain and userspace was reported at tinycc-devel mailing list which caused hours and days of bug-tracking and testing to support some arbitrary improvement of C-standard" <aggi>it's been fixed already, but remains a hindrance to bootstrapping regardless <aggi>so, tinycc-devel already did block against bootstrapping indefinitely, and HEAD cannot be pulled as initial steps/0.9.26->head <aggi>this blocker could have another side-effect, that is riscv64/aarch32/aarch64 support with tinycc are/were done on HEAD to my knowledge <aggi>although tinycc itself my have remained conservative with C-lang for itself, even when it supports some gnu/C11/... magic <aggi>another question, since live-bootstrap picked tcc-0.9.26 for good reason, if there was any other reason to upgrade to 0.9.27 at all <aggi>because now, then it's two versions of tcc involved fallen behind HEAD for almost 10years <aggi>i don't know yet if it's either feasible or desirable to roll-along with HEAD (although i had to re-test entire linux-tcc kernel and tinycc/os userspace fork of 500builds if that passed with 0.9.26 or 0.9.27) <aggi>don't know either if pnut could digest a tcc-head, and even when if that was desireable at all <ekaitz>aggi: tcc has been a little bit confrontative towards the bootstrapping effort <ekaitz>i think that's what you can see in that message by janneke in 2017 <aggi>ekaitz: i've noticed some weird statements from tinycc-devel myself, some guy arguing bootstrappable.org supposedly mis-represented bootstrapping efforts, which i tend to disagree with fundementally <ekaitz>i have also been treated with disdain by grishka in the past <ekaitz>i just don't understand the guy's attitude <ekaitz>people asking for releases for years... <aggi>it isn't, and so far tinycc-devel did help with re-establishing linux-tcc kernel support and a few other details <aggi>i was wondering only why, since from the beginning tccboot and linux were a major target of tinycc, why that's not been maintained/tested for a decade <ekaitz>there are a few people that are very helpful <ekaitz>but the code is really hard to follow and the maintainer's attitude isn't great <ekaitz>i was asked in the past to stop sending commits to the mob branch by some dude because he wanted to push for a release <ekaitz>so his way of making that was by freezing every single developer in the planet <ekaitz>one of my goals in the bootstrapping is to remove it from our chain in guix <aggi>well, i expressed concerns over tinycc becoming destablized (which it has been), but didn't mean to halt it's development by pointing to that fact <ekaitz>but anyway, i like the idea of tcc and how they solve their goals <ekaitz>but having such a passive-aggressive maintainer is a high burden <ekaitz>and the tcc codebase could be way more readable <aggi>i'll probably try if tcc-head can be digested by pnut, which will regress against live-bootstrap then <aggi>so far, i've extensively regression-tested compile-time and run-time tcc-mob/head with linux-tcc kernel and tinycc/os userspace fork, and this does work on x86_32 with a few known issues only <aggi>if such a nightly-build CI setup was established, it too could be easier for tinycc-devel to re-produce some of these from a common baseline <aggi>and for such a setup, i too think it's desirable to keep the dependency graph a tad bit smaller <aggi>i think it's cosinusoidally and his tcc-bootstrap-alt which points to a principle issue with tinycc too <aggi>since the initial tcc version there is 0.9.2 which could be and was spawn from M2 directly i think <aggi>while latest tcc mob/HEAD may not be spawn from M2? (and requires some additional intermediate C-compiler/interpreter such as mes-cc/pnut/stack_c/tcc_cc) <aggi>because, live-bootstrap already did fork and blocked at tinycc-0.9.26, maybe it's been an earlier version of tinycc which got infringed for bootstrapping and in general? <aggi>and with any later it's not that big of a difference if it was 0.9.26, 0.9.27 or HEAD since none of these could be spawn from M2? <aggi>yet for some reason cosinusoidally too rushed towards a latest HEAD, probably because only this could compile gcc-4.x? <aggi>even when tcc-0.9.2 was rather capable otherwise? <aggi>i've not tried to push linux-tcc kernel and tinycc/os userspace with such an old tcc version, and TCCBOOT did use 0.9.21 already which could not be spawn from M2 <aggi>so, what's been a STABLE release of tinycc? 0.9.2? <aggi>for all i know, bellard himself departed from his own project and since then it was discarded to a branch dedicated as "mob"? <aggi>because, otherwise, it could not have been used to spawn gcc-4.x? <aggi>but then, maybe it was possible to spawn some gcc-2.7/9 from tinycc? (at the time when gcc got hijacked by egcs) <ekaitz>aggi: gcc 2.95 was in the guix bootstrapping chain before <ekaitz>we skipped that going directly to 4.6.4 <aggi>another aspect with this, linux-kernel, because tinycc did need upgrades for some linux-2.4 which was the LAST Bellard bothered with up until 0.9.21 <aggi>i've noted linux-kernel for problems with 16bit real-mode support in another context only (finally tinycc missed 16bit ASM completely) <aggi>although there was some attempts and patches for tinycc, long time ago, but this didn't make it to support linux-2.4 anymore <aggi>for that matter, the first bootstrapping approach, this had been TCCBOOT long before, not live-bootstrap <aggi>but tinycc-devel and Bellard too quit <aggi>QEMU is a whole other topic, which i postponed since i could not backport this either <lanodan>ekaitz: With the idea of removing tcc from guix bootstrapping which compiler would it be? Another small one like cproc/chibicc/… ? <aggi>sh4: well then, which is the last stable release for a complete system integration and bootstrapping completed? <sh4>hmm? release of what? and what does it got to do with my message? <aggi>a complete release, including assembler, kernel, libc, userspace, bootstrapping. <sh4>you're refering to a distro? <sh4>i talked about the blasphemous C standard function prototype in your tcc mailing list mail <aggi>nor any suitable C-toolchain which remained stable <sh4>-xfwrite(buffer, size, count, file, submode, islast) <sh4>that's what i'm talking about <aggi>that's done on latest mob/HEAD, not any other <sh4><aggi> [15:06:32] "An examplary case for C-standard de-stabilization affecting entire toolchain and userspace was reported at tinycc-devel mailing list <sh4>it's no blasphemy, it's just ancient pre-ansi K&R <sh4>a real case for a C-standard de-stabilization attempt is Annex K as proposed by microsoft and acked by the committee