IRC channel logs
2022-08-12.log
back to list of logs
<oriansj>theruran: stikonas is correct. All M0 files are valid M1 files as well and with care M0 can also build M1 files for a single architecture. <stikonas>in practive we are not careful enough to keep to uppercase hex immediates <theruran>I noticed prototype_lisp cannot read some deeply nested lists in ascension.scm <theruran>fails on line 193 of lisp_read.c and gdb tells me `p head`: $1 = (cell *) 0x0 <theruran>if I enter get-index line by line it will work though <oriansj>theruran: probably a bug in the garbage collection <axxi>struggling with, bootstrapping gcc-4.7.4, compile/linking with BUILD=arm-tcc HOST/TARGET=armv6-musleabihf <axxi>i remember boostrappable.org confirmed gcc-4.7.4 compiled/linked with x86_64-tcc <axxi>anyway, binutils-2.22 linked/compiled with arm-tcc already, musl-libc almost done, almost, and ~700 userspace builds <axxi>oriansj: does this project contain a confirmed gcc-4.7 bootstrapping with tcc compiler? <axxi>thanks for the hint stikonas[m] <axxi>could this route be confirmed for BUILD=arm-tcc HOST/TARGET=anyarm-hardfloat? <axxi>nothing wrong with that (x86 i mean), and there's some nasty side-effects with arm eabi linkage occasionally, for example <axxi>any reason for gcc-4.0.4? <axxi>i chose 4.7.4 because it was the last one known to remain c-only if desired <stikonas[m]>Possibly had problems building dependencies of newer GCC with stable tcc <axxi>ok. since i made some considerable progress with tcc on git-HEAD (jan-2022), gmp/mpc/mpfr are all compiled with arm-tcc already, and most of gcc-4.7.4 too <stikonas[m]>Also live-bootstrap has no pregenerated files, so some extra requirements <axxi>i utilize gentoo-crossdev still, for the regular cross/toolchain maintenance, with some patching this is mostly stable for any cross-compile desired and supported with gcc-4.7.4 <axxi>now working on tcc-integration <axxi>this is the type of trouble currently, when statically linking gcc-4.7 with arm-tcc: tcc: error: Unknown relocation type for got: 106 <axxi>i'll try dynamic linking again <stikonas[m]>I was never able to get dynamic linking working in lived bootstrap <axxi>ideally, i can remove GNU-toolchain/gcc/binutils entirely, however i want to ensure then tcc (and possibly elfutils) can bootstrap the GNU-toolchain <axxi>meaning, i want the entire userspace and kernel pass compilation/linking without gcc/binutils <axxi>there's some nasty blockers remaining <axxi>host: CC=arm-tcc LD=arm-tcc AS=arm-tcc AR=ar >>> sys-devel/gcc-4.7.4 merged. <aggi>anyway, compiled an entire userspace (~600builds currently), with tcc compiler <aggi>and some blockers are noteworthy, what required patching, and/or version-downgrade <aggi>such as iproute2-5.x utilities, yet couldn't be compiled with tcc compiler... <aggi>libffi(for python)... required as build-dependency for some... recent iputils (meson) <aggi>net-dns/bind ... c11 threading didn't pass with tcc compiler or gcc-4.7 <aggi>as an alternative, busybox contains some userspace utilities for network-admins... <aggi>busybox build-system freaks out over gcc-specific extensions entangled into the makefiles <aggi>toybox is missing implementation for various ip utilities <aggi>not sure what bootsrappable.org covers in it's entirety <aggi>i try to maintain an entire _userspace_ compiled/linked with tcc _only_ <aggi>linux kernel is on todo still, for compilation with tcc... remember susematz tried and didn't finish <stikonas>aggi: well, there is not precise definition what bootstrappable covers <stikonas>there is a lot of low level stuff done here <stikonas>i.e. bootstrapping simple C compiler from hex <stikonas>then we also have bootstrap chains from there to GCC. But like I said yesterday, this only works on x86 (unlike lower level stuff which is often done for multiple platforms) <aggi>stikonas: some issues with low-level parts are blocked with arm-tcc still <aggi>unsupported GNU asm syntax and/or missing implementations with arm-tcc assembler <stikonas>aggi: by low level parts I mean much lower <stikonas>by the time we reach tcc, it's considered quite high level... <stikonas>but e.g. how do you build tcc in the first place? <aggi>i am well aware of what you mean... <aggi>too back-tracked this, to GNU Guix and their bootstrapping for gcc-2.7... <aggi>and digged down deeper into, what i consider a "supply chain", including hardware <stikonas>but we can do stuff like hex0->hex1->hex2->M0->M2-Planet->mes->mescc->tcc where hex0 is 256 byte binary <jbowen>To bake an apple pie from scratch, you must first invent the universe <aggi>it's just, to my knowledge, the procedure to bootstrap gcc with guix was documented with gnu guix, including a rather big binary bundle with some scheme etc <aggi>no clue, how to begin with a wozmon, and arrive at a compile such as tcc and a bootable system <aggi>at the lower hardware level... i arrived at Gigatron TTL, as a side note only <stikonas>still it's impressive how much tcc can build... <stikonas>I saw it too when I worked on live-bootstrap <stikonas>though sometimes quite a bit of patching is needed <aggi>it is too noteworthy, what fails with tcc, because i want the userspace parts to contain a self-hosting development environment <aggi>which can compile everything... <aggi>situation surrounding busybox and the networking utilities, is just one example among many others <stikonas>well, we had some trouble building musl initially <aggi>too stumbled upon some very nasty dependency graphs with gnu-autotools/perl involved <aggi>yep, with musl there is some minor blocker remaining too, on aarch32... which is some unsupported ASM syntax in crt*.S files <stikonas>gnu-autotools/perl is solvable, we managed to completely bootstrap autotools and perl <stikonas>yeah, on x86 there was some unsupported asm syntax too <aggi>currently i am struggling with GNU gettext btw... which is requires as a bdep <stikonas>no, I haven't tried building gettext with tcc since we first built gcc 4.0.4 without gettext and then used gcc to build gettext <aggi>elfutils is another problem (because i want a non-GNU toolchain without binutils/gcc being capable to bootstrap a gnu toolchain) <aggi>elfutils are cluttered with unsupported C11 __thread extension <aggi>it's a long list of such problems <aggi>i maintain the repositories and dozens of patches with gentoo-tooling, to keep this reproducible with all logfiles <aggi>python is another issue, in _userspace_ <stikonas>well, at some point I would like to get portage working when starting with live-bootstrap <aggi>i try to avoid python, and will keep rolling with gentoo (gcc-4.7 c-only toolchain system profile for aarch32/aarch64/amd64) in parallel to a c-only tcc-toolchain profile <stikonas>well, you can't avoid python with gentoo... <aggi>meaning, i got several automated system-integration paths <aggi>with gentoo, i blocked at gcc-4.7/binutils-2.22 with a c-only toolchain system profile, and can compile/cross-compile/upgrade wherever i wish <jbowen>How frequently do you run into issues emerging packages with that setup? <aggi>and, that's the idea, which is already implemented, i can emit a tcc-toolchain profile, with the tcc-toolchain i'll minify the package set down to what can be maintained _without_ gentoo <aggi>jbowen: my overlay contains ~300 ebuilds currently <aggi>in total the userspace (with which i retained most legacy c-only variants of various software) currently contains ~600 ebuilds <aggi>anyway, arm-tcc can compile/link both gcc-4.7 and binutils-2.22 already, and 99% of all ebuilds <aggi>what remained as blocked currently, is rather concerning nonetheless, although it's only handfull of builds <aggi>anyway, i'd like to coordinate those efforts with like-minded developers <aggi>next one, gnu gettext (and intltool), are wrecked when compiling with tcc... not sure where this will hit me as a build-time dependency... <aggi>it's a dozen of builds only which depend on gettext as bdep... sys-apps/shadow and app-crypt/pinentry for example, weird <aggi>i'll try to fully remove gettext as build-dependency <aggi>not sure, where dev-util/intltool will hit the build system <aggi>ideally, i can fully remove gcc and binutils <aggi>the alternative route to bootstrapping of those which i can confirm: arm-tcc compiler/linker seemed to fully digest those toolchain parts, meaning it won't be locked out <aggi>however, gettext and intltool could bite somewhere, not sure yet... i'll know soon enough <aggi>another problem, which is hitting heavily concerning bootstrapping <aggi>uboot loader on aarch32/64... which requires python-swig and a c++ compiler <aggi>python itself is blocked against arm-tcc compiler because of libffi and incompatible ASM syntax <aggi>python-swig is written in c++, which of cause cannot be digested by arm(64)-tcc <aggi>however, the cross-compilation setup from-to aarch32/64 <-> amd64 is stabilized with gentoo crossdev and the c-only toolchain profile <aggi>hence, i can use both amd64 and aarch32/64 as a development base <aggi>the criteria are: c-only toolchain profile, no c++ <aggi>everything compiles/links with tcc compiler/linker and elfutils (no binutils, no gcc, no llvm) <aggi>another criteria, the tcc-toolchain with a c-only system profile does _not_ lock out bootstrapping gcc/binutils (done already, except some potential quirks with gettext/intltool) <stikonas>argh, annoyingly hex2.efi that I wrote tends to stuck occasionally. It works maybe 80% of the time, so there is still some bug left