Good Afternoon, Minor notice, another night-shift and heading towards a complete TinyCC driven Operating System release: finally, dev-lang/python passed static compile/linking with i386-tcc. Initially two python extensions - _ssl/hashlib and xml/expat/elementtree - fail runtime-testing with a segfault, hence those are removed temporarily, portage utilities are working still.
And a complete devdrop i586-tinycc-linux2-musl.iso compiles again, which should sufficiently test-cover tinycc python.static. Soon, i can see to _all_ utilities remained self-hosting and pass runtime-testing with portage on the final i586-tinycc-linux2-musl.iso development host (coreutils replaced with busybox and a few others could bite, no big issue), and with it if a TinyCC driven OS release remains fully self-hosting. This wasn't possible up until recently because python/portage were blocked against tcc for a very long time. Since python/portage passed: 1) python can be bootstrapped and remain self-hosting with i386-tcc and 2) optional gentoo-tooling can remain self-hosting with i386-tcc and 3) publication would not be blocked by an urgent re-write of packaging of ~500builds maintained with portage currently, because python/portage are unblocked for extensive testing against i386-tcc now. A recent perl-5.36.0 version besides the older perl-5.8.6 passed with i386-tcc already too; the latter supported with tcc and bootstrapping, the former supported with tcc _and_ cross-compilation beyond different ARCH; with autotools/autoreconf and python/ portage the major system-integration tooling is available, both for bootstrapping and self-hosting. Publishing this isn't trivial, because it's an all-or-nothing with the forked portage-tree/patched ~500builds/musl-libc etc. which was several years of work. git-pushing any sources isn't problematic, but i rather do so with a dedicated project domain to host operating system devdrop releases themselves in parallel. As an alternative, i could dissect individual ebuilds with their patch-folders each, and publish those only depending on what's of interest to bootstrappable or tinycc-devel; but this would complicate re-producing test-cases without a release-tagged bootable ISO of mine. Another side note: i would not hesitate to publish _everything_ to bootstrappable and tinycc developers; but i hesitate to do so for _everyone_ else for various reasons, including the fact i may not want to lose control over a TinyCC driven Operating System release without the opportunity to establish a dedicated project-site hosted by myself due to absent resources, meanwhile anyone else could easily scrape and salvage for hosting it with a shiny web-site, while i can't myself. And I think a complete somewhat-POSIX operating system release fully supported by a *nix type compiler/toolchain such as TinyCC is rather valuable, too as a baseline for any other OS/ARCH/CC variant (for example bsd|riscv|cproc etc), given a verification against i386-tcc partially covers relevant issues for any other such approach. Furthermore i keep test-coverage for some other ARCH|CC|cross-compilation variants with CC=gcc4|tcc ARCH=arm,x86 and crossdev some of which is not relevant to tinycc-devel, but important to be retained with the test-setup because i386-tcc alone can't provide full test-coverage yet. Sorry for the somewhat over-extended status reporting. That's it for a little while. Suggestions to coordinate efforts are welcome. On 2025-05-05 05:12, Michael Ackermann via Tinycc-devel wrote: > On 2025-05-04 20:39, Detlef Riekenberg via Tinycc-devel wrote: > > > > How to handle the recent mail about a cross compile issue on arm host? > > > > > > TCC has more issues, but when we wait until every issue is fixed, > > a TCC release will be postponed for another 5 years. > > > > -- > > Regards ... Detlef > > > > To report and handle issues test coverage should be sufficient to detect any. > Hence a complete distribution compiled/linked with TinyCC could be relevant. > > I'm fighting tooth and nail a sufficiently complete GNU/POSIX base sytem > profile > including development utilities were confirmed against TinyCC toolchain, > for i386-tcc native at least. > > However, besides TinyCC development itself, additional development and > maintenance efforts for any such system had to be considered. > As a consequence, the demand for any TinyCC release too could involve that of > a > sufficiently complete Operating System distribution release driven by it. > > Good news is: mentioned i586-tinycc-linux2-musl.iso system does compile and > boot > Bad news is: i'm hitting limits with time, money, resources dedicated to this, > since i had to fork kernel, fork libc, fork a portage tree of ~500 builds. > > So far dozens of cooperation requests, at local university, various prominent > employers, in Germany, etc. were hit by a brickwall of denial and ingorance. > I'll keep you updated with any release/git-push asap; current situation > doesn't > permit any further publication indefinitely. -- Michael Ackermann
signature.asc
Description: Digital signature
_______________________________________________ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
