Hello,

I have a few questions related to running dynamically-linked binaries on musl. Let me start with a few statements which I feel are relevant:
1. I'm currently on Void Linux, amd64 architecture. My musl version is 1.1.24_12, I'm guessing it's either unmodified by the packaging or only slightly tweaked. Either way, I'm assuming other users' experience is similar.
2. This isn't specifically a troubleshooting question, I'm not really expecting to get a simple solution to my problem. If I do get one I'm going to feel like a clown for making such a long OP.
3. I don't really want to switch back to glibc because of laziness and I'm probably more inclined towards the philosophy of musl anyway. This is also the reason I chose this libc implementation in the first place.

Now onto the problem.

Trying to run dynamically-linked binaries, usually games, results in errors with loading shared libraries, or `symbol not found`. Here's a specific example of Factorio:
Ldd results in many more `symbol not found`.

Then there are also strange problems with SEGFAULTs on some of my programs. I'm pretty sure these are related to libc, despite being statically-linked - I think they call some c libraries during runtime (ldd would suggest this). However, I don't know how to debug this further, and it's been a while since I wrote it. If anybody is interested in details feel free to ask.

Here are my questions, in no particular order:
What is your experience with musl-related errors?
What are the prospects of these issues being fixed? I'm assuming the only good solution lies in improving musl, but perhaps I'm wrong, and the project has no interest in resolving these - I can see many reasons for such an approach. Also I'm unfamiliar with the state of the project in general, so I'd appreciate any information from somebody more knowledgeable.

The way I understand it, software needs to be compiled against the libc your going to be using at runtime, just like any other lib. As far as I know, these two competing libc implementations are not intended to be binary compatible with each other since that would pointless and offer no advantage.

If I remember correctly most independent projects that support Void, supply 2 packages. One for musl, and one for glib.

1 members found this post helpful.

I just checked and their FAQ page states:
> Yes and no. At both the source and binary level, musl aims for a degree of feature-compatibility, but not bug-compatibility, with glibc. [...]
> [...] Binary compatibility is much more limited, but it will steadily increase with new versions of musl. At present, some glibc-linked shared libraries can be loaded with musl, but all but the simplest glibc-linked applications will fail if musl is dropped-in in place of /lib/ld-linux.so.2.

So I expect either a compatibility layer will eventually be released or the library will become more compatible with binaries at some point in the future.

I don't think (almost) complete compatibility between musl and glibc would be pointless, since musl strives to be faster, simpler, more correct, etc. - all of which doesn't necesarily imply non-compatible behaviour (bugs are an exception to this, but porting bugs isn't really reasonable anyway).

Additionally, I have no reasonable way of compiling proprietary software for musl, since I have no access to source code. Sure, a case for open source could be made here, but I'm talking about convenience, games, and some rust libraries, which are the only ones I can do anything about.

I can confirm that Void packages work fine.

Hmm, that interesting, thanks for sharing. I wasn't aware that musl was aiming for a drop in replacement for glib. I guess it's been several years since I've started with Void. I just chose glib since I needed to develop software to run on a "regular" linux distro.