<aggi>how could python be bootstrapped without a python interpreter? in comparison i think perl doesn't require a perl interpreter itself for this. <stikonas[m]>aggi: python only needs python for rebuilding pregenerated header files <aggi>stikonas[m]: allright, i only checked the gentoo ebuilds and the dependencies noted there, and both pypy2/3 and python2/3 insist on a binary bundle of themselves <aggi>in comparison, with perl, a miniperl interpreter is compiled from C-only, and then this miniperl is proceeded with <stikonas[m]>So I don't think there is much difference between perl and python <stikonas[m]>Hmm, unless newer python 3 started using python for more stuff <aggi>ok, i want to remove python3 as a build-dependency anyway (gentoo), however i do not want to lock-out python(3) bootstrapping later, because my release won't contain any python anymore <aggi>if python3 can be bootstrapped without a binary bundle from C-only with tcc compiler later then this problem is solved too <aggi>i want to rentirely remove GNU-toolchain (gcc/binutils), i don't want to lock-out a bootstrapping of gcc/binutils, but i do not want to depend on this anymore <aggi>i arrived at huge userspace builds already, including mplayer/ffmpeg and several dozens of libs/dependencies... _all_ of this passed with tcc <aggi>well, downgrading back to gcc47 and a c-only toolchain profile was almost one year of work, and bootstrapping gcc47 with arm-tcc again was another few days of hackjob <aggi>it's not me who intended to lock out <aggi>it is only a handful of ebuilds remaining to repair, including linux kernel and it's Kbuild system <aggi>i know with certainty already, this Kbuild system depends on gcc specifics, such as 'gcc -S' to output asm instead, whatever this is good for <aggi>not sure yet... some weeks ago i made a first test run with kernel-5.10 and arm64-tcc <aggi>current blockers remaining: musl-libc (unsupported aarch32 asm), kernel (kbuild system issue, aarch asm), perl (miniperl compiled with arm-tcc fails during runtime) <aggi>it's not that much anymore, and it's feasible (which i didn't know if a tcc-toolchain _only_ is feasible, it is) <aggi>on aarch32/64 with uboot loader a nasty dependency graph against python/swig/c++ remains, however x86/64 there isn't <stikonas[m]>Well, building modern kernel with tcc won't be easy... Thought it would be a useful knowledge <aggi>meaning, i can fully separate the _entire_ distribution from GNU-toolchain and LLVM alike <aggi>stikonas[m]: i think it is possible, and feasible, with reasonable efforts <aggi>and it is very desireable to do it, given where GNU and LLVM are heading <aggi>and, don't underestimate the mountain of problems, in _userspace_, which is done 99% already (except minor issues above mentioned) <oriansj>aggi: well it really always was inevitable. People who create languages only think of their best interest. People who uses languages only think of what makes them happiest. Cultures always die due to their own waste products. <aggi>meanwhile, re-verified elfutils and tcc-ar utilties, and it seems GNU buildystems feeds unsupport options into which only AR=gnu-binutils-ar can process <aggi>another 30 builds, potentially wrecked by GNU <aggi>i mean, such problems can be solved, nonetheless, if anything, i do not want to depend on GNU with anything anymore ***roptat is now known as Guest8836
***mateusz is now known as mattx
***lukedashjr is now known as luke-jr