Herman, thanks for the ultra-quick response of yours.

Since the recent issue is an exemplary case, this deserves elaborating a little
upon future challenges, and i may skip C-standardization for a moment:

In fear of regressions introduced de-stabilizing further, i _intentionally_ kept
it at some tinycc-version which was known to pass with a complete system-compile
/boot including the recent self-hosting one that succeeded, because there was
other more or less nasty regressions before, and any regression now might affect
a set of 500ebuilds instead of kernel/libc build "only". And there's a few more
runtime issues spotted since recently, which i can't report all at once
(problems with versions later than >app-shells/bash-4.1 and
 >app-arch/tar-1.22.91 when compiling/linking with tinycc)
So, with hundreds of patches and hacks all over the place i've too been forced
to backtrack various components to make this work initially somehow, and i
cannot and will not regression-test compile-time and run-time in worst-case 500
invidividual components against several different tinycc-versions.
That's just impossible and something i want to prevent.

I too want to avoid dragging tinycc-devs into distro-maintenance tasks. Hence,
I'm in the middle in between cleaning up chaos before git-committing a notable
amount of staged changes which were required again (not all of this is related
to tinycc by far, given portability towards linux-2.4/linux-5 and other aspects
were involved).

Alltogether it would be feasible already to do regular(!) nightly builds of the
entire tinycc-driven distribution tracking tinycc changes, which might catch one
or another regression compile-time or runtime immediately, since just as said
after 3 years of 24/7 hackathon i've arrived at self-hosting this.

I'll quickly git-pull tinycc latest HEAD regardless for this one test-case,
given there's been recent changes to tinycc related to the problem disclosed
with cdrtools/mkisofs run-time, as you've said.
In this case i too may have to rebase a few changes to tinycc ebuild, because
i had to patch a little into tinycc itself too (cross-compilation, handling of
unknown arguments, minor nasty things). Thats another reason why i rather
fully stabilize any iteration before rebasing, which i can't do that often given
the workload to maintain TinyCC/Linux distribution.

I'll prioritize the cdrtools-related issue temporarily, because currently i
_must_ avoid any regression hitting a tree of 500 ebuilds + kernel + libc;
and i'll not pull into latest tinycc HEAD before CI for some nightly builds are
established, which besides technical issues involves some political ones.

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

> _______________________________________________
> Tinycc-devel mailing list
> [email protected]
> https://lists.nongnu.org/mailman/listinfo/tinycc-devel


-- 

Attachment: signature.asc
Description: Digital signature

_______________________________________________
Tinycc-devel mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Reply via email to