Took a little while, made a complete test-run with latest tinycc HEAD against the complete tinyfront system:
$ i386-tcc --version tcc version 0.9.28rc 2025-12-17 HEAD@34eed88a* (i386 Linux) RESOLVED: - reported issue with function parameter parsing spotted in cdrtools/mkisofs is fixed with latest tinycc-version (thanks @herman) - app-shells/bash-5.x weird run-time behaviour vanished, it's working now which simplifies retaining portage-tooling that relied upon latest bashism because portage tooling doesn't need further hacks to avoid it - bash.static, perl.static and python.static suffice to drive forked gentoo-portage and GNU-autootols system-integration tooling self-hosting - complete tinycc-driven distribution passed self-hosting compilation and run-time testing while re-compiling itself, which besides compile-time too implies notable runtime-testing passed - linux-2.4 Kbuild passed compilation and booting as usual some grsecurity, NPTL among other patches seem stable, SMP works CONFIG_HIGHMEM for 4GiB RAM confirmed on HP T620 thin client; optional PAE for up to 16GiB RAM may need testing but worked while ago (https://codeberg.org/aggi/linux-tcc) - bridged-networking inside virtualbox with linux-2.4/tinycc Kernel didn't work for an unknown reason (for example PCNet failed set link-state); now it's working when compiled with latest tcc-version, ping wan/lan ok - AHCI/Sata locked up kernel-boot; tested again, it's working now, PATA/IDE and usb/flash-memory support available anyway I couldn't track all tinycc changes to associate them with any root-cause, and i can't say with certainty if it's some other side-effects, but alltogether it seems some changes made to tinycc in recent month significantly benefit stability! UNRESOLVED/TODO: - tinycc-compiled app-arch/tar-1.34 mis-behaves; unknown root-cause, not urgent, busybox-1.2.2/tar and tar-1.22.91 tested OK - AX8872 rev. a/b/c usb-ethernet dongle backported to linux-2.4 suffers from instability bug with large packets send (nfs, ssh-transport); unknown root-cause, sporadic connection-losses and kernel deadlocks - tinycc C-pre-processor (cpp) cannot be used in conjunction with rpcgen utility from net-libs/rpcsvc-proto required for NFS; not urgent, workarounds exist - tinycc x86 assembler cannot process some little 16bit real-mode boot-code; not urgent, workaround exists - upgrading Kbuild beyond linux-2.4; not urgent, linux-2.4 is a decent kernel still to retain a development baseline with sufficient hardware support; otherwise: - linker script support missing - gcc -S equivalent missing - dynamic linking support with musl-libc was not possible; not urgent, static linking is fully supported to retain a development baseline - linux2.4 can be compiled both AoT (done regularly) or JiT with tccboot; the latter was confirmed with linking some recent 0.9.27 tcc-version while ago for JiT/tccboot, not urgent, it's feasible still - extensive runtime-testing beyond self-hosting compilation; so far IRC, links-browser, NFS, SSH, mplayer/audio etc. tested OK - re-writing gentoo-portage ebuilds for some other packaging with cross-compilation support, something less hostile towards POSIX, without bashism and without python dependencies; not urgent because python/perl/bashism are available, too much effort; shipping a release with portage-tooling involved more easily permits tracking and re-producing bugs - spawning the system from bootstrappable.org at the stage tinycc got bootstrapped; tinyfront covers the transition from gcc->tinycc, while bootstrappable.org covers the transition from tinycc->gcc->g++->... it's both possible, re-confirming the complete bootstrapping chain is neither urgent nor blocking other tasks - complete CI setup for nightly builds and devdrop releases; blocked for political reasons - upgrade test-domain at http://tinyfront.mooo.com for some stable hosting at https://tinyfront.org; blocked for political reasons - re-iterating over the basic system component package set for desirable additions (kertex TeX implementation, ghostscript upgrade, whatever else) or removal of components; it's rather complete and useful already - considerations for a minified TinyCC/Linux release, with busybox-1.2, tcc, cdrecord/mkisofs, git, and most basic dev-utils shipped only; easily done; not urgent, maybe suckless.org showed interest in such a development host for their ubase/sbase instead of busybox, so suckless too may detangle from gcc/c++/llvm? In principle, issues of a tinycc-driven distribution should be separated from tinycc issues, because i do not want to emit further distribution maintenance noise onto tinycc-devel mailing list. Hence, I've finished some cleanup-tasks and Automated/Scripted nightly-builds are feasible, the _technical_ basis for this exists since recently. A complete TinyCC/Linux release would need some work still, to upload distfiles, a few dozen git repos, webhosting, bug-tracker/ticket-system, including gitweb for the forked portage tree. The complete development setup can be delegated then for colaboration and mutual benefit with a little time and effort. The _technical_ basis for nightly builds exists since recently. It's a major success, i would say for entire FOSS even, since when most recent software versions can be detangled from c++/gcc/llvm and driven by a real unix-like C-compiler/toolchain such as tinycc. It's too a development baseline re-established to port for and with tinycc any other than ARCH=x86_32 or other kernels/versions than linux-2.4, if anyone else wished to do so. However, for unrelated political reasons I cannot git-push any further currently, since again all contracting was denied in Germany ("EU") when contacting several dozens of employers and some universities again. That's it for a little while, other tasks to cope with ahead. Feedback appreciated. Wish you all pleasant holidays. Michael On 2025-12-16 14:07, Michael Ackermann via Tinycc-devel wrote: > > Concerning nightly builds of a tinycc-driven distribtion i'll open another > thread soon. > > ttyl, > Michael > > On 2025-12-16 13:43, Herman ten Brugge via Tinycc-devel wrote: > > Op 16-12-2025 om 11:46 schreef Michael Ackermann: > > > > Greetings. > > > > Didn't show up on tinycc-devel for a while, so let me start with the good > > news: > > Since recently a self-hosting compilation of a complete tinycc-driven system > > succeeded, after almost three years of 24/7 hackathon of mine it's a > > major break-through! > > > > As introductory note for the reasoning behind i want to mention some > > documentation again which was put online at a tiny test-site here: > > [1]http://tinyfront.mooo.com/docs.html > > > > Besides compile-time testing of tinycc now this too involves notable > > runtime-testing with alot of programs that were compiled by tinycc itself: > > > > $ i386-tcc --version > > tcc version 0.9.28rc 2025-02-13 HEAD@f8bd136d* (i386 Linux) > > > > This time a problem occured with mkisofs.static compiled/linked with tinycc > > which the following patch circuumvents. > > > > diff -Naur cdrtools-3.02.orig/mkisofs/write.c cdrtools-3.02/mkisofs/write.c > > --- cdrtools-3.02.orig/mkisofs/write.c 2025-12-12 11:34:19.000000000 -0000 > > +++ cdrtools-3.02/mkisofs/write.c 2025-12-12 11:40:04.000000000 -0000 > > @@ -165,13 +165,7 @@ > > #define FILL_SPACE(X) memset(vol_desc.X, ' ', sizeof (vol_desc.X)) > > > > EXPORT void > > -xfwrite(buffer, size, count, file, submode, islast) > > - void *buffer; > > - int size; > > - int count; > > - FILE *file; > > - int submode; > > - BOOL islast; > > +xfwrite(void *buffer, int size, int count, FILE *file, int submode, BOOL > > islast > > ) > > { > > /* > > * This is a hack that could be made better. > > > > > > Current tcc is at: > > tcc version 0.9.28rc 2025-12-15 mob@8569427 (i386 Linux) > > We made some changes this year in this area so please try latest > > version. > > Herman > > > > References > > > > 1. http://tinyfront.mooo.com/docs.html --
signature.asc
Description: Digital signature
_______________________________________________ Tinycc-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/tinycc-devel
