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: 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. Without this patch, tinycc-compiled mkisofs.static reports a runtime-error: - when count=1 is passed into the function - an error handler reports count=0 instead (see source of cdrtools for details) Obviously tinycc may have a problem with parsing function defintions when those follow a yet unknown standard. The bug inside tinycc compiled mkisofs.static is concerning, because: 1) it's hit RUNTIME, not compile-time, hence difficult to spot 2) circuumventing this would require a review of almost all sources (500ebuilds) for the syntax peculiarity if this occured anywhere else 3) the root-cause of this bug isn't isolated so it's not confirmed if patching cdrdtools for example merely hit some side-effect. i've noted weird issues with other packages (app-arch/tar, app-shells/bash) In particular tinycc compiled bash.static caused notable headache because i had to roll-back to version bash-4.1, any later bash-5.x too mis-behaved when compiled/linked with tinycc and bash.static was needed by the forked portage tooling that i'm using still, anyway Now i'm in the situation i would want to release some devdrop bootable tinycc-driven distribution for tinycc-developers to re-produce such issues, but quality hasn't passed pre-alpha stage testing yet, and i wouldn't want to drag tinycc-devs into annoying distro maintenance tasks. And it's just not desireable to ship a system which contains mentioned type of bugs. Anyway, i haven't got a final solution to this problem but would propose: - a tinycc command line option to disable support for whichever standard that was which made tinycc pass parsing such a function definition without reporting a compile-time error but instead produced mis-compiled binaries which hit weird runtime-errors. such runtime-errors are far more severe than compile-time errors reported. - and of cause it's desirable to repair tinycc in case documented variant of function defintions shall be supported it's parsed and compiled correctly then (don't know which C "standard" that followed anyway and this may deserve a separate discussion if it was worth supporting any such "standard" while producing mis-compiled binaries. no offense towards tinycc intended, but it's an exemplary case) There was alot more to talk about a TinyCC/Linux type system on the horizon, which already did pass compile-time and run-time testing with a complete system being bootable and self-hosting. Just as said it's good enough already to re-compile itself with 500ebuilds involved, including all required development utilities. However, i've had no luck yet either with any contracting nor support when contacting dozens of employers and universities again. End of november after 6 month my documents had been reviewed by a university for hiring as professor there, this deadline just was crossed again, so i'm left hanging in the middle of nowhere in germany, which besides technical issues is another severe hindrance of political nature to git-pushing any further, although i do want to share all results with tinycc developers and bootstrappable some of whom did help with re-establishing C-toolchain support for a GNUish/POSIX type system. Nowadays, after 20years, the TinyCC/Linux variant seems the only one remaining, because almost all other known POSIX systems are locked into gcc (lunix,fiwix) and/or transitioned to llvm/clang (BSD, minix). And since i've began hacking this three years ago, meanwhile upstream transitioned further entangling into C11/c++/rust/etc. So I would say the tinycc-driven system profile that i could salvage already with most recent userspace software-versions may be the last chance for "free software" to re-establish C-toochain support and C-toolchain portability with it. At minimum a development BASELINE for any such approach other than i586-tinycc-linux2-musl could be reastablished too. Other than bug-hunting it's alot of cleanup-tasks remaining, since it was hundreds of patches and hacks required all over the place. At least it's zipped into a forked portage tree for comfortable tracking, all logfiles archived and it's fully automated with some scripting. In the meantime until a few technical and political issues got settled so I may release the system for mutual benefit, I'll try my best to support tinycc with errors disclosed by integration testing. Feedback appreciated. Thanks. Michael --
signature.asc
Description: Digital signature
_______________________________________________ Tinycc-devel mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/tinycc-devel
