IRC channel logs
2025-01-21.log
back to list of logs
<stikonas>but generally it will be needed for your further bootstrap <stikonas>glibc needs python if you'll build glibc based system later on <stikonas>or it could be useful to e.g. bootstrap Gentoo <stikonas>I think fossy was considering moving it to "optional" extension <stikonas>but we decided that python is fairly central part in most modern distros, so you'll probably need it <matrix_bridge><Lance Vick> I only use live-bootstrap to bootstrap a cross compiler, and finally a native gcc13 stage3 <matrix_bridge><Lance Vick> then my native packages go on to build everything else, including python, llvm/clang etc <matrix_bridge><Lance Vick> are there any steps in live-bootstrap I can drop that are not strictly required to build a gcc/binutils/musl cross compiler? <matrix_bridge><Lance Vick> the only thing I actually need to bootstrap directly from hex0 is x86 gcc13/binutils/musl <stikonas>I think python is the only thing that you can drop <stikonas>well, that's why we left it in live-bootstrap <matrix_bridge><Lance Vick> true, but I am wondering if the only reason we build openssl is for curl <matrix_bridge><Lance Vick> openssl is built just before ca-certificates and curl indicating dependency <matrix_bridge><Lance Vick> so ill drop those in this next build and we will see <matrix_bridge><Lance Vick> at this point the only thing I am still using from live-bootstrap are most of the pass*.sh files which I call directly individually, and helpers.sh. <matrix_bridge><Lance Vick> at this point I am wondering if I should just vendor those <matrix_bridge><Lance Vick> I assume the LICENCES folder indicates the project is licensed as basically everything, so this is no problem? <matrix_bridge><Lance Vick> then there is no dead code people need to audit for stagex <stikonas>LICENSES folder mostly reflects license of various patches that we ship withing livebootstrap <stikonas>patches keep their original license from upstream software <stikonas>we can't change that (and no need to do that anyway) <matrix_bridge><Lance Vick> Yeah fair. Just wanting to evaluate options. (and open to other ideas too!) <matrix_bridge><Lance Vick> our use case has some overlap, but only a little bit at this point from the goals of live-bootstrap <matrix_bridge><Lance Vick> Can punt on that for now. Let's see how small I can -actually- get these steps to see how much work we are really talking here to extract just those bits. <matrix_bridge><Lance Vick> flex is needed for bison which is needed for bc, and ed is also only needed for bc, and bc is only needed for the linux kernel headers, which I also don't think I actually need bc for? and I could use busybox bc worst case built from tcc which can build uber fast, and also probably eliminate the need for coreutils and friends <matrix_bridge><Lance Vick> I could also likely build busybox very very early. Like, just after the first tcc. Then could probably skip all versions of bash, and coreutils, tar, xz, bzip2 <matrix_bridge><Lance Vick> The actual minimum viable path to x86 gcc13 may actually be pretty short... <matrix_bridge><Lance Vick> Tell me if I am smoking something, but this -seems- viable to me: mes ~> musl ~> tinycc ~> make ~> busybox -> acr ~> intermediate musl/gcc versions ~> gcc13 <lanodan>Is acr supposed to be a drop-in replacement? <lanodan>At least it seems more like yet another alternative way of creating a ./configure script. With the same flags as ones generated with autotools, which most ./configure scripts do. <lanodan>Plus for autotools compatibility you'd probably need to keep m4 (and likely GNU m4), the thing is pretty much a framework after all. <lrvick>though, maybe I run m4 and company to generate the actual final compile commands each project needs <lrvick>commit those in the pass files directly <lrvick>then can drop perl, autotools, autoconf, m4 <lrvick>running in a vacuum with fixed filepaths etc, we don't really need any autodiscovery/autogen magic. All we care about are the final CLI commands to compilers <matrix_bridge><Andrius Štikonas> lrvick: you can get to GCC13 much faster if you don't try to rebuild all pregenerated files... <matrix_bridge><Andrius Štikonas> As for busybox, it probably won't build with meslibc <aggi>you might distinguish packages into: crucial development utilities, and optional extensions; then next dimension those packages which need autotools, and those who don't <aggi>the intersection then is: crucial development utilities shouldn't rely upon autotools early during bootstrapping <aggi>several options exist to meet this criteria <aggi>for example, with the approach of tinycc fully replacing gcc, busybox replacing coreutils, a few autotools troublemakers are avoided <aggi>binutils are a special case, that oasis-linux coped with by stripping upstream buildsystem <aggi>and since binutils are necessary for kernel and/or tccboot load an alternative was to rewrite those bootloader.S assembly parts for as86 syntax <aggi>fiwix and/or linux24 are fully supported by tinycc/as86 then, and with tinycc,as86,busybox (bundled into a minimal-i586-tinycc-linux-musl.iso) the development utility package set should be almost complete <aggi>sufficiently complete to bootstrap a complete GNU with including gcc/binutils/bison/autotools <aggi>besides oasis-linux, aboriginal linux (Rob Landley) demonstrated how such a minimal development host setup can be bundled <Googulator>One problem I see is that modern GCCs require Autogen, and therefore, Guile <Googulator>Unless there's a replacement for Autogen as well <Googulator>or perhaps a version of Mes that can run Autogen <lanodan>Heh autogen is something I have masked on my gentoo installs <lrvick>so you think modern gcc can actually build without autogen? Should kick tires <lrvick>stikonas: I also have to re-generate all pre-generated files for my threat model as well. Next step is to switch to VCS sources directly and not trust ar archives even, to avoid what happened with XZ where vcs and archive did not match, or pregenerated files being compromised <lrvick>I was able to drop python, curl, openssl, and everything after gcc13 without issue though <lanodan>As I said, I don't have autogen on my gentoo machines, yet I do have gcc. <lanodan>And looking in toolchain.eclass autogen is only pulled in when tests are enabled. <Googulator>maybe in GCC 10, autogen is tested by configure even if tests are disabled? <stikonas>lanodan: it's not tests but the build system that needs it <stikonas>gentoo does not rebuild all the build system from source <stikonas>but uses some files that maintainers prebuilt and added to release tarball <stikonas>if you try to build GCC from git repo, you would notice missing autogen much quicker <stikonas>oh, they actually comitted that Makefile.in to git repo... <stikonas>though it is clearly generated (and that is also indicated by a comment at the top of the file) <stikonas>Makefile.in is generated from Makefile.tpl by 'autogen Makefile.def'. <stikonas>Makefile.in is 68973 lines long way too much to read <stikonas>whereas Makefile.def + Makefile.tpl are 758 + 2165 lines. Far more reasonable... <lanodan>Ah yeah committed to git is why I wasn't seeing it, because there is git-based versions for gcc in gentoo. <stikonas>it's mostly just used as templating engine <aggi>seems up until gcc-4.7.4 calling autoreconf -if doesn't need guile; not sure if this re-generates all files or if i missed anything else <aggi>with gcc-4.7 i build gcc-6.x (for aarch64 cross-target, c++ etc. support for example), and guile wasn't asked for with autoreconf <aggi>i've explicitely added autoreconf -if to toolchain.eclass and all ebuilds, guile wasn't needed anywhere <aggi>I see, gcc-4.7 too uses a pregenerated Makefile.in, regardless of autoreconf <aggi>didn't bother yet with autogen/guile support for the tinycc system profile; live-bootstrap must have arrived at autogen/guile somehow _before_ compiling gcc with tinycc <aggi>parts.rst "Luckily, building GCC without top-level ``Makefile`` is fairly easy." <stikonas>aggi: autoreconf doesn't regenerate everything <stikonas>it's Makefile.def autogen definition + Makefile.tpl template file -> Makefile.in file <stikonas>that autoconf later processes into Makefile <stikonas>but those early source file (.def and .tpl) have nothing to do with autotools <stikonas>hence autoreconf wouldn't know that it needs to regenerate themn <stikonas>but yes, GCC and binutils is not really one project <stikonas>so you could indeed run individual autotools in subdirectories <stikonas>though it's somewhat hacky but it mostly works