IRC channel logs
2025-11-19.log
back to list of logs
<agg1>mid-kid: still trying to bootstrap gentoo for and with tinycc-toolchain <agg1>so far i managed to see ebuilds kicking, it's not passing a complete crossdev run yet to emit a complete bootable system self-hosting <agg1>perl/python/bash were very tricky to retain those with tinycc compatible with portage tooling <agg1>good to see portage can be spawn from bootstrappable already <agg1>for some weird reasons, i think gentoo should be bootstrapabble _without_ gcc/binutils/llvm/clang and using tinycc for this instead <agg1>not specific to gentoo either, a complete system should be bootstrappable and self-hosting with tinycc <agg1>difference then is, gentoo/portage aren't locked against gcc and/or llvm/clang exclusively <agg1>i mean, the tinycc-driven system does compile and boot already, but it's not yet self-hosting with portage-tooling <agg1>the proceeding then is: bootstrappable -> tinycc driven system, without gcc/binutils etc, portage tooling available -> bootstrapping gcc/binutils with portage tooling available <agg1>which has both advantages and dis-advantags; with regards to bootstrapping gentoo/portage and gcc/binutils there's no relevant benefit over the existing bootstrapping <agg1>the advantage is the tinycc-driven system itself: <agg1>- too spawn from bootstrappable <agg1>- cross-compilation confirmed for the entire system profile <agg1>- fully detangled from gcc/binutils and/or llv/clang <agg1>- all development utilities available, maintained with tinycc, such as gdb, strace, etc. <agg1>- fully sanitized from all c++ dependencies <agg1>and, this is what i'm hacking into still, portage tooling available both bootstrappable and self-hosting with tinycc <agg1>i've named the approach "c-toolchain portability", to keep a system fully portable towards and with different c-toolchains other than gcc/binutils and/or llvm/clang <agg1>initially motivated by the trivial fact, nowadays gnu and llvm are c++ toolchains, which introduced a transitiv dependency towards c++ _always_ even when base-system software was written in C (kernel, libc, busybox whatever) <agg1>tinycc is much faster than gcc, and it could be a little more comfortable to have a bootable ISO that was bootstrapped itself, but contains all development utilities driven by tinycc to spawn any other system <agg1>furthermore, could be considered either an advantage or disadvantage, porting a complete GNUish/POSIX towards and with tinycc exposed software quality issues <agg1>and next, ensuring c-toolchain portability establishes a _baseline_ for any other such approach, such as Kefir compiler for example <agg1>anyway, i'm just glad, seems i found a bash-version which is compiled correctly with tinycc (no segfaults when handling brace expansions), and does support sufficient bashism for portage tooling <agg1>with regards to bootstrapping gentoo/portage with tinycc, i've had to block at and patch specific versions of perl, python, bash <agg1>maybe various package versions should be kept in sync and maintained among gentoo, bootstrappable, and tinyfront <agg1>portage tooling itself is blocked indefinitely already, and i had to fully fork an entire portage tree of ~500ebuilds for support with tinycc <agg1>due to this, among other issues, gentoo and other mainline distros _lost_ c-toolchain portability <vasi>fossy: Excited by your attempt at Debian, that would be great to have <vasi>mid-kid: Love the prefix approach! <mid-kid>vasi: thanks! there's still things to improve, but I kind of prefer this cross-compiling approach over whatever the official bootstrap-prefix is doing. Thinking of ways to upstream some of the weird changes I'm making. <mid-kid>agg1: Your effort is commendable, and I hope you manage, but at this point I think you're better off hard-forking and building your own ::gentoo compatible portage tree that can then build the "real" ::gentoo portage tree, kind of like what live-bootstrap is doing with its early vs late stages. <mid-kid>I just don't think you can keep a c-only system maintained for very long - if it's not c++, then it's the Rust dependencies sneaking into things like python. <mid-kid>Just a matter of time before live-bootstrap needs to bootstrap rust from mrustc or something, that'll be a doozy. <mid-kid>(gentoo recently officially added an mrustc bootstrap to their tree which is awesome) <jackdk>yeah even some of my hardcore rust enthusiast friends are not keen on the Rust-in-Python proposal, given that there are no musl-based linuxen on Python's list of officially supported platforms and Python is a build dep of glibc <mid-kid>lanodan: I've tried to use it before, with the ROOT= option, to create a bare-minimum install to build the rest from. <mid-kid>But the canonical way to do what I was trying to do use the profile's packages.build with USE="-* build $BOOTSTRAP_USE" <mid-kid>bootstrap.sh falls apart because it doesn't properly support non-gcc/glibc profiles. <mid-kid>So after, I think, my gentoo-2024 bootstrap, I haven't used it since. <mid-kid>bootstrap.sh's usefulness would go up significantly if it was just a script that performed catalyst's stage1, that being `USE="-* build $(portageq envvar BOOTSTRAP_USE)" emerge -1e $(all_the_package.build.packages)` <mid-kid>It was fairly difficult to find out that this was what was being done for stage1 btw, I've never liked how catalyst code is so catalyst-specific. <mid-kid>So that's why I first tried bootstrap.sh, I knew about it before I knew about catalyst. <agg1>yes mid-kid, i've forked the entire tree, for several reasons; including portage tooling <agg1>don't know yet which version of gentoo/portage you've bootstrapped, because i cannot keep latest portage tools anymore <agg1>otherwise, USE=-cxx isn't anything new, it just lost it's meaning inside main tree in recent 10years <agg1>because gcc-4.x was phased out, and there's not been any efforts for tinycc (c toolchain portability) either <agg1>i'll have a look at your work, once portage tooling is self-hosting with tinycc <mid-kid>USE=-cxx is just there for libraries with optional c++ bindings, which sometimes need extra deps and etc. But you're right in that you can't build a system without c++ anymore. <mid-kid>USE=-wayland and USE=-rust are heading in the same direction, for KDE profiles and all desktop profiles, respectively. <agg1>there's much more than USE=-cxx though, it's a helpful criteria though, because it catches many other inderectly related problems <mid-kid>agg1: I doubt my work is useful to you, I'm assuming a C++-enabled version of GCC and a bunch of other tooling present at the end of live-bootstrap. <mid-kid>my goal is to just extend live-bootstrap itself with extra steps to build a gentoo system. <agg1>that's why it's interesting, because i've initially spawned the tinycc driven system from a gentoo build-host <agg1>it's just good to know, i can trust bootstrappable and your efforts, and focus on the c-toolchain portability related issues <mid-kid>cosinusoidally: it seems like they're still allowing rust for optional modules within cpython. we'll see what that entails, but at least it might be avoidable unless they allow porting existing optional modules to rust. <mid-kid>like I expect to still have some 5-7 years or so, during which it can be avoided, but seeing how quickly it became mandatory on my desktop systems, it feels like just a matter of time before one of the foundational projects needs it. <mid-kid>APT is another such project that recently spawned a bit of controversy. <matrix_bridge><cosinusoidally> mid-kid: yep and to be fair to the Python maintainers at least the explicitly mentioned bootstrap considerations if Python depends on Rust (and the circular dependency it would create as Rust already depends on Python to build). <mid-kid>I hope live-bootstrap can become a bit of a mainstream "source of truth" to refer to when talking about how things depend on eachother to bootstrap. <mid-kid>I also hope that Rust will change their mind about depending on version N-1 to build each consecutive version, it's really annoying with how long the builds take. <agg1>"In comparison rust-lang follows a vendor specification but not any standard.^2" <agg1>"Without any vendor-neutral standard followed development cannot agree upon a common baseline of which releases or versions of rustc could compile itself" <mid-kid>your site is blocked at my office for "Pornography", so I'll have to read it at home. <mid-kid>but yeah the lack of healthy multi-vendor competition is what puts me off of rust as a core system language as well. <mid-kid>while there's alternative implementations of rust, they're stuck in an eternal state of playing catch-up. <mid-kid>having experienced what playing the cat-and-mouse game with a game consoles company over exploits and workarounds is like, I don't wish that sort of development lifestyle upon anyone. <agg1>pardon? there's zero pornography, none <srazkvt>mid-kid: the alternative implementations aren't complete for the version they target <matrix_bridge><cosinusoidally> probably zscaler or something misclassifying it since the page is http <srazkvt>mrustc works to compile rustc but it does a lot of assumptions about the correctness of the code, and gcc-rs can't compile most of the core part of std <mid-kid>every time you've finally built something you're proud of, you're anxious over when, not if, it will be broken again by the entity holding the cards, leaving unhappy users and you picking up the pieces and building back up again, for the 15th time that year. <mid-kid>I guess it's less bad with language development, depending projects don't start using the new language constructs *that* quickly, though I've seen people release things using the new language features within the week or so <mid-kid>but yeah I don't wish to be a rust alt-implementation maintainer... <mid-kid>srazkvt: Yeah that's true, I'm just saying *if* any of them ever catches up, the churn is still rough. <matrix_bridge><cosinusoidally> I think JavaScript is one of the few languages that actually meets the requirement of having a specification and multiple independent high quality implementations. It also backwards compatible too (which is handy as I can continue to write in ECMAScript 5.1 forever as I think every later version was a waste of time). <agg1>i tend to disagree, since rust-lang dependency creeped into massive-scale, into critical base system components where neither c++ nor rust-lang belonged, never ever <matrix_bridge><cosinusoidally> and I avoid stuff like npm since that's a whole other mess. <agg1>besides, have not tracked JS interpreters, but you mustn't miss transitive dependencies, either build-time or run-time <lanodan>And JavaScript is also one of the rare languages with it's official testsuite being open-source. But yeah npm (and browser) space is a can of worms. <agg1>and who knows what shows up in the dependency graphs for JS, in violation of standards, even when JS itself follows standards <srazkvt>yea rust as a language is very hostile to new implementations, not because you'd be shunned, but by how the thing just goes full speed ahead <matrix_bridge><cosinusoidally> All of the JS JIT compiler are in C++/Rust, but there are C only implementation like duktape, quickjs, and mujs. <srazkvt>doesn't help the rust ecosystem really wants to redefine how the system as a whole works, which, doesn't actually work <nimaje>agg1, mid-kid: my guess would be that the block is for *.mooo.com <agg1>it's not my domain, just picked a free dyndns subdomain entry from a provider, doesn't matter <mid-kid>nimaje: yeah coroprate firewalls are a mystery to me, it's never been fair. <matrix_bridge><Andrius Štikonas> It might be because you are on dynamic dns