longish post about chimera and glibc compatibility woes
i'm not really sure how to feel about people creating chimera forks that use glibc or whatever for the sake of compatibilitythe thing is
i'm not gonna diss the effort if someone thinks it's worthwhile but
chimera's toolchain is very purpose-built and most of its choices were already driven by specific reasons and it's all put together to be clean, work well, be highly portable (hence why we still support like 7 archs), etc.
now someone goes and pulls glibc into the mix; assumptions break, so one has to also pull in gcc and binutils at some stage, and of course since glibc dlopens an unwind library do do stuff like non-portable pthread_exit stack unwinding, pull in the hacky llvm-libgcc and effectively revert to making the base toolchain layout gcc-centric again (and break portability as llvm-libgcc has to closely simulate per-arch symvers and do that individually for each arch, which is another thing glibc pulls in that is unnecessary with musl)
now, this still does not get you proper compatibility with existing binaries as you're missing libstdc++; if you want libstdc++, you can't have libc++ with libc++abi in the base, as libstdc++ does not allow you to replace its abilib symbols, which are folded into libstdc++ itself; it may look like it "works" if you just pull in a libstdc++ build into such system, but effectively you are pulling two sets of core abi symbols into the same process in a very unsafe way, so if you want to make this safe, you have to make libstdc++ always present, and build libc++ against it, at which point you're pulling more gcc dependency into the core and at which point you may as well decide to just use libstdc++ in the first place (why pull in two c++ libs?)
at this point you may notice you're pulling more and more of the general gnu/linux stack in because you don't have any other choice, and things get hackier, uglier, etc
and the compatibility argument is imo inherently flawed, because where do you actually stop? everyone has a different line defining what is "compatible enough"
eg the chimerautils tools will break a ton of preexisting scripts, and there is a ton of other unconventional stuff in chimera as is, that is not intended to be backwards compatible
if you want a system that is fully compatible with existing stuff, you might as well use like, debian or fedora or whatever
OR, you can just accept things as they are and help work towards making the stuff you want work
in userland, you have containers etc which you can use to get stuff that doesn't work yet to work (or for proprietary software), and there are ways to make that pretty seamless
i guess if you have like, an nvidia graphics card that's one of the unfortunate cases, but everything else should be pretty much doable...
i'd much rather like to see the work go into improving what we have
