<mid-kid>I'm sure the requirement of python3 for building glibc is well understood here but <mid-kid>I'm wondering whether it's a better idea to build musl+gcc with dynamic linking support first <mid-kid>Or wrestle with python to get it to work in a static environment <mid-kid>I'm sure somebody here has already bootstrapped glibc on the live-bootstrap environment, right? <stikonas[m]>In particular if we want to replace autogen templating... <mid-kid>wouldn't it just be building musl with --enable-shared? <mid-kid>and dropping --disable-shared on gcc <fossy>so far, it isn't appearing to be very difficult to build python staticially <mid-kid>yeah I ended up managing it's just the module system that's less than ideal <fossy>i'm working on bootstrapping python now for live-bootstrap btw <oriansj>mid-kid: to your question of which would be better, I don't know but which looks more like fun is probably the best course <fossy>one reason why i am a fan of static linking particularly for live-bootstrap is because we have many versions of everything which sometimes doesn't play well with dynamic linking <mid-kid>Yeah but for the later/final stages it's less of a concern <fossy>yep, when we jump to final gcc/binutils/glibc triplet we can probably change over to dynamic <Hagfish>python for live-bootstrap is a great project. i look forward to following that <mid-kid>for now building gcc with --disable-lto and building python with some builtin modules seems to bypass the need for dynamic linking for the purposes of building glibc so far. <stikonas[m]>There are some more issues to fix before dynamic linking works ***samplet` is now known as samplet
***HaxCPU is now known as WaxCPU
***unmatched-paren_ is now known as unmatched-paren
<lanodan>Anyone here managed to bootstrap Erlang without having the BEAM binaries? <stikonas>lanodan: what are BEAM binaries? I'm personally not very familair with erlang <stikonas>if they haven't done it then the answer would most likely be no <lanodan>I look in both NixOS and Guix, looks like they are both fine with beeping the beam files <stikonas[m]>Well both of them are not super strict about pregenerated files <stikonas[m]>Though I think usually byte code is removed if somebody does tgr job <stikonas[m]>Well, I guess no Erlang in live-bootstrap any time soon :D <muurkha>Debian usually is super strict about "fails to build from source", but they're okay with the "source" being human-readable pregenerated files <muurkha>I know. That's why I mentioned that :) <stikonas>and I converted catm.hex1 to catm.hex2 on riscv32 and riscv64, will be easier to maintain it in higher level hex <stikonas>especially on riscv there is quite a bit of difference between hex1 and hex2 <stikonas[m]>Just tried hex0.efi on my laptop. I think it runs fine <stikonas>now we need to port kaem-optional (though it would be called bootx64.efi)... <stikonas>well, first I guess I need to reduce the size of kaem-optional on x86 and amd64 before porting it to uefi...