Date: Thu, 24 Dec 2015 12:04:42 +0700 From: Рысь <lynx@...xlynx.tk> To: musl@...ts.openwall.com Subject: Re: musl & proprietary programs On Wed, 23 Dec 2015 18:00:12 -0200 Alba Pompeo <albapompeo@...il.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
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.