Introducing Casuarina Linux: A glibc-Based Chimera Linux Derivative
42 points by wezm
42 points by wezm
Congratulations! It's a big endeavour and I hope you enjoy it.
One observation:
remaining binary compatible with the wider GNU/Linux ecosystem
Is it using libstdc++? It looks like it isn't:
Casuarina is comprised of LLVM toolchain, ...
After that LLVM is built and all other packages are built with LLVM.
Is it using libstdc++? It looks like it isn't
System packages use LLVM's libc++, but libstdc++ is also available for compatibility.
this is mostly impossible to (safely) do else chimera would already have it
if you build a system around libc++abi, putting libstdc++ in will duplicate the base abi symbols, which may "seemingly" work but is unsafe
and libstdc++ has no way to replace its underlying abilib, so if you want libstdc++ compatibility, you're falling back to gcc becoming your base toolchain
Thanks for the details. Seems I have some homework to do.
In FreeBSD, we build libcxxrt as a shared library. Out libc++.so is actually a linker script that looks like this:
GROUP ( /lib/libc++.so.1 /usr/lib/libcxxrt.so )
When we were in the transition phase, we also patched libstdc++ to dynamically link against libcxxrt instead of statically linking libsupc++. It is possible to do this, but it's work: you need to patch libc++'s build system. This was easy for the libstdc++ in base because we weren't using gcc's build system at all. It's painful with libstdc++'s one. The libc++ build system lets you explicitly set the ABI library to use.
Google has a successful story mixing libc++ executables and libstdc++-using DSOs. They need a custom libstdc++ that strips libsupc++ symbols (C++ ABI library) to prevent collision.
If libsupc++ symbols are kept in libstdc++, C++ exceptions across DSO boundaries may cause crashes. In addition, layout mismatch in std::runtime_error might lead to crashes.
It's interesting that these days glibc is the compatible approach. I remember when it came out, there was quite a bit of brouhaha, as all the binary packages linked against the old Linux libc suddenly weren't usable anymore. This, combined with the move to the ELF format (replacing the old a.out one) caused Jessica Parsons to create Mastodon Linux which had quite a lot on its plate: old binary format, old libc, probably old kernel versions to make this work. And it tried to switch to a BSD userland (one of the earlier distros that tried to do this).
I’ve felt that Chimera is Void Linux's sibling in this space. I’m curious: what feels substantially different about Chimera's stack, like the build system and init, that makes it appeal to you over xbps and daemontools?
I really enjoyed my time on Void even with some of the extra chores of having to step in and help keep packages up to date. Plus xpbs-src is very flexible. One could just use void and its base packages as a platform and install another package manager like lix, linux brew, or guix on top of it. Chimera has had my attention for a bit but haven't tried it yet.