IRC channel logs
2026-02-12.log
back to list of logs
<aggi>trying to salvage at least one TeX implementation to pass with tcc <aggi>arrived at tetex-3.0... which ships with 20year old configure.in and additional m4 macros <aggi>so far i did not need to pull an old autoconf/automake version for such problems, and patched dozens of configure.ac/makefile.am elsewhere <aggi>with TeX it's several concerns (although not directly related to bootstrapping, but c-toolchain portability and indirect impact onto build system with autotools) <aggi>first, all modern major TeX are gigantic in size and complexity, for this reason alone some older tetex-3.0 got some appeal still <aggi>then, next, in this case, autotools regressions, given i'v been doing autreconf/configure patching and testing for 24hours already - for just one package <ekaitz>aggi: what about luatex? lua is easy to build <ekaitz>i don't know about the size of luatex <ekaitz>(oh it's not written in lua, but added lua! :( ) <aggi>ekaitz: thanks for the hint; not sure if luatex adds some c++ dependency graph <aggi>i've merely looked at the gentoo portage ebuilds of texlive, and that's scary <ekaitz>aggi: it looks more like they added lua to pdflatex than that they wrote it in lua, which is what i thought <aggi>in comparison the tetex dependency graph is moderate, except for the autotools clutter <aggi>besides tetex-3 candidate there is only one other remaining, from plan9 realm kerTeX which got ported to *nix <aggi>but that ships with yet another confusing build system <aggi>inside tetex-3, there is only one c++ dependency, [lib]xpdf which i guess can be removed once i got the autoreconf salvaged <aggi> well, it's not funny, don't feel like laughing about this <aggi>rather shout into the pillow <aggi>thing is, of cause tcc can bootstrap some gcc/gnu and then any TeX spawn with it <aggi>but, i do want a long-term stable TeX system with C-toolchain portability remaining intact shipped with TinyCC/Linux <aggi>for that matter, pdf support at framebuffer terminal compiled/linked statically with tinycc does work already (that was a nasty hackjob too) <aggi>but TeX! it's that important i am shocked when staring at what we got nowadays <FransFaase>I have shown that it can replace stage0 and build the first steps (mentioned in the manifest file) up to and including tcc-0.9.27 resulting in a tcc executable with the same SHA256 hash. <FransFaase>All the necessary utilities (from cp to ungz) are compiled with the alternative compiler that I have written with only making some small modifications to the source files. <FransFaase>For far, I have only implemented this for x86 target. The next task (Task 5) will be to support this also for the other 64 bits targets. <FransFaase>Although it no longer uses the GNU Mes compiler, it does still depend on the sources for compiling the initial standard library. <FransFaase>The next target I will start working on will be x86_64 target. <aggi>FransFaase: i've noted your projects on TODO for review since i've not yet re-confirmed neither live-bootstrap nor your work <aggi>i think that was related to utilizing shell-script as emulation host, something LaurentH was working on <aggi>don't know yet if and how that was related to each other <aggi>sorry for the confusion if any <FransFaase>aggi: I do understand the confusion. They are not related indeed. Apologies accepted. <aggi>"70TB of space and lots of bandwidth" <aggi>seems a little more concerning than the hardware issue, although i don't know how common 70TiB scale hosting was <aggi>at a smaller scale, i was syncing gentoo distfile mirror, that blew up my 1.5TiB RAID "out of space" <aggi>since chromium alone dumped >1GiB of gibberish once or twice a week with each of their release <aggi>meanwhile i've wiped all c++ dependencies, backported everything i could onto tinycc/linux-2.4 <aggi>and 99% of the distfiles folder wiped; nonetheless it's a complete GNUish/POSIX system remaining driven 100% from source with tinycc <aggi>except, TeX/tetex-3 for example, whose autreconf/configure phase passed an houre ago, but there's a few compilation errors remaining <aggi>a nasty one btw. since it's some code-generator involved, which emits .c|h with some getline() definition clashing with stdio.h <aggi>i guess it will take a little while until foss community realizes the threat model of a 70TiB single point of failure <aggi>which, in a way is too related to bootstrapping, given that's the final target of it <aleksih>janneke/ekaitz: In mes NEWS, it reads that mes-libc 0.28.0 is capable of compiling upstream tinycc. Does this mean that mescc+mes-libc is robust enough to skip tinycc-bootstrappable at that point? <stikonas>I haven't checked latest branches, but a few months ago somebody managed to do it <stikonas>it was fairly big single-commit change, so needed refactoring <stikonas>but surprisingly a lot of stuff that was patched out in tinycc-bootstrappable is no longer needed for upstream tcc <stikonas>e.g. not disabling floats ended up rounding those to integers or something like that <aggi>the code generator inside TeTeX is nasty, it's some pascal-to->c|h generator, which emits getline() clashing with stdio.h <aggi>the pascal sources are a mixture of tex and pascal, which grep -R can't spot the getline function definition with... argh <aggi>i got a solution in mind, postprocessing the c|h files with some inline sed 's/getline/getln/' inside the makefile target for these <aggi>the pascal templates themselves seem some unformatted/pre-generated sources too... awful <aggi>and, without c++/g++, of cause, i can't compile the pdf-output processors <aggi>djvu should work - but this seems a whole other story of proprietary and patent interests <aggi>otherwise, since a few weeks the tinycc/linux system is deployed into production i've fixed several dozen of bugs <aggi>many of which weren't related to tinycc, but linux2 ABI for example, sntpd/ntpclient did not sync reliable for example, now it does <aggi>most important, no more kernel panics - although this requires some concerning workaround still (reported on tinycc-devel) which indicates some bug inside tinycc <aggi>as said before, the idea is live-bootstrap (or pnut-sh, or the work from frans) to spawn tinycc with, then linux2 kernel (ideally without the real-mode 16bit binutils dependency), and atop of this a complete userspace <aggi>which there seems not much missing <aggi>tinycc preprocessor got some limitation still, can't be used in conjunction with rpcgen/nfs <aggi>i've pre-generated those, and there's some sysvr4 cpp which i'll checkout once tetex is done <aggi>ghostscript is blocked at an ancient version 7.07, but it's good enough for fbpdf at framebuffer <aggi>and, tinycc probably can be fixed and/or a latest ghostscript version patched (i didn't succeed trying thrice) <aggi>bottom line, withe tinycc/linux approach this: 1) shrinks the dependency graph significantly (depending on the package set desired) and 2) the available package set is significant <aggi>including the scientific authoring utilities etc. <aggi>recently i've stumbled upon glib (that's coming from GTK)... i kept glib-1.2, which should suffice for GTK2 i think (although i won't bother with this) <aggi>nonetheless it is feasible to spawn GTK2 with tinycc (except some unicode pieces iirc) <aggi>i'll too try QEMU again with tinycc <aggi>mplayer/libsdl1/prboom, passed compile-time, had no time yet for runtime testing of this <aggi>some mp3 played just fine on some old thinkpad whose onboard audio is supported <aggi>got no usb-audio, but this should work too, linux2 had it <aggi>ffmpeg is there, but i have to review the video-out modules again which differ between linux2 and linux5(drm) <aggi>after all, ffmpeg originated from Belard too, same with tinycc <aggi>a notable amount of builds could be integrated without autotools even <aggi>i'll finish the TeX "bootstrap" next, maybe i'll retry plan9 kerTeX too since tetex is a pain and hasn't got pdf-output finally (without g++ available) <aggi>QEMU isn't urgent, since tcc/linux2 runs on bare-metal x86_32 just fine <aggi>but, if tinycc/linux should be a bootstrappable development host, a qemu-riscv64 could be relevent (for me it isn't) <aggi>i'm thinking of a whole other project already, that is salvaging AX.25 with tinycc/linux, for some SHTF radio stack <aggi>the system won't fit onto floppy disk, but an 8GiB USB-flash should do, including all sources/distfiles <aggi>static linking and debugging symbols suck alot of disk-space, so i've given up the idea to fit this onto some DVD-sized.ISO <aggi>given mirror.kernel.org needs 70TiB nowadays for kernel "only", it's fascinating to think a complete tinycc/linux-2.4 passed with ~8GiB total <aggi>and i've backported alot of stuff <aggi>maybe this could be bundled with a collection of documentation/ebooks <aggi>in case internet goes down, to keep a develoment host running, which can stay connected, with ax.25 for example, and modem-dialup <aggi>with a realistic size limit of data <lanodan>I've seen it before, probably not here but still take it as too extreme for it's own good and effectively taking a wrong path. Like if you pick OS bootstrapping then you reproduce in different machines to (in)validate it, you'll need that anyway due to baked-in ROMs (in a way the last true ROMs). <lanodan>Like I think it effectively went past the goal of requiring everything to be built from source and the environment (such as compiler) not corrupting the build, and instead went into "full source, chicken-egg all the way to the first unicellular egg"