Re: musl & proprietary programs

[Рысь <lynx@lynxlynx.tk>]

On Wed, 23 Dec 2015 18:00:12 -0200
Alba Pompeo <albapompeo@gmail.com> wrote:

> I also don't want to pollute my system with glibc. That's why I asked
> if there was any plan to improve musl support of proprietary programs
> like the ones I listed.
> But as a last resort, I think Rich's method is the best so far, but
> I'm a bit lost on the details since I'm not a libc expert.
> I couldn't find a wiki page detailing Rich's method on Void or Alpine
> (the 2 distros I know use musl). Is there a step-by-step for a novice
> somewhere?

There is also problem that musl wishes not to be fully glibc compat.
Certain libc structs and public structs coming from glibc headers that
are not required to be ABI same will be different on musl for
performance or optimization reasons, and programs relying on them
usually will not be happy. Simple programs probably still will work.

I tried to hack into this area back in 0.9.x times (Jul2012). I even got
userspace nvidia libraries being loaded by plain musl into `glxgears`
and it did worked. Last time I revisited that was in Jan2015, and musl
was greatly "improved" - applying same changes then trying to run the
same `glxgears` resulted in plain segfault. From Jan2015 I was running
X server in chroot, and completely moved to nouveau by Mar2015.

Software that loads many-many shared objects, including modern GUI libs
will BE unhappy. Just because when building with glibc result binaries
are much polluted with glibcisms. My case was simpler.

-- 
http://lynxlynx.tk/
Power electronics made simple
Unix and simple KISS C code