Idea for one linux repo to work on both musl-based and glibc-based systems

[jrmarino]

I suspect the musl library exists just fine on glibc based systems.
So it should be possible to make musl a port, one that is pulled in all linux builds with the USES=musl module.
In this case, glibc would not be part of the system root.

So all linux packages would be built against musl, which would allow packages to run all ALL linux platforms.
The only trick would be to force the major library version to be something unique so it wouldn't clash with the musl lib on musl-based systems.

[jrmarino]

I guess the key is to get ravensys-gcc to build with musc-c instead of glibc.

[groggily]

I think it's the other way around. You can install glibc on musl-based distros and just use the normal glibc-based binary packages.

[kraileth]

Sorry for being skeptical, but how would that work? On distributions like Void which offer two editions for glibc and musl respectively, /usr/lib/libc.so is either the former or the latter. Glibc chroots are supported where you put a glibc package somewhere in /$SOMEPREFIX/usr/libc.so and then chroot to it. Then glibc packages will work there. The same could be done the other way round, too. And musl is actually packaged by quite some glibc-based Linux distributions, but that contains the headers and the libc.a file for static linking. I don't think having two libcs as equals would work, would it?

[jrmarino]

e.g. /raven/lib/libc.so.888 <---- raven built musl c.

packages link to it rather than {systemlibs}/libc.so.x (can't remember what X is)

both libraries co-exist and the real-time linker figures it out.

[kraileth]

Well, in that case I don't see why it wouldn't work. However that means introducing a new dependency that would be redundant with the system libc. The benefit would of course be a package set that basically only depends on a recent enough kernel and not too much else. Hm ...

[jrmarino]

in theory you could take it to the extreme. for example. llvm is building a c library that isn't mature yet. but if it reached the level of musl, in theory we could provide identical system libraries to ALL platforms (same math lib, same c lib, etc). it would become a true sandbox where every system could be configured generically (not freebsd, netbsd, linux, etc), just "raven".

probably not practical (especially with wildcards like systemd) but its a fun thought experiment.

[kraileth]

A fun thought experiment for sure! Are you familiar with the CloudABI project (https://github.com/NuxiNL/cloudlibc) that Ed Schouten did several years ago? I think it was an awesome idea.

[jrmarino]

the choice between musl and glibc is not so straight-forward:
https://edu.chainguard.dev/chainguard/chainguard-images/about/images-compiled-programs/glibc-vs-musl/

[jrmarino]

this is pretty crazy

glibc "wins" is several other important areas though

[jrmarino]

from what I read, going musl everywhere would cause a lot of problems.
In reality, especially given usage share, we would go the opposite direction -- provide glibc on musl-based distros. Still one repo, but using glibc as the standard