|
Message-ID: <CAJDAfTB82BjcEE-V6d6cmJHUaVjJSPcDTQ1n=mJOAyFR_Q+Jzw@mail.gmail.com> Date: Wed, 23 Dec 2015 18:00:12 -0200 From: Alba Pompeo <albapompeo@...il.com> To: musl@...ts.openwall.com Subject: Re: musl & proprietary programs 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? On Wed, Dec 23, 2015 at 4:51 PM, Рысь <lynx@...xlynx.tk> wrote: > On Wed, 23 Dec 2015 12:43:52 -0500 > Rich Felker <dalias@...c.org> wrote: > >> On Thu, Dec 24, 2015 at 12:22:05AM +0700, Рысь wrote: >> > On Wed, 23 Dec 2015 15:48:53 +0100 >> > Szabolcs Nagy <nsz@...t70.net> wrote: >> > >> > > * Alba Pompeo <albapompeo@...il.com> [2015-12-22 13:37:52 -0200]: >> > > > chroot is a little better than dual-boot, but still very >> > > > unfriendly for a day-to-day usage of many proprietary tools. >> > > > >> > > >> > > on x86, binaries linked against glibc can be made to work with >> > > musl. >> > > >> > > but isolating such software into a separate virtual environment >> > > is a good idea anyway and then it's easier to use glibc based >> > > userspace there. >> > >> > Well that's fine until you will not face something dynamic. A simple >> > example: some of my machines successfully runs LibreOffice 4 inside >> > Slackware 14 chroot. Problems start when user wants to save a >> > document to USB stick. This is a valid use case, but fails because >> > you end up with mounting USB stick twice. This requires wrappers. >> > And in *DE environments they will be lost under pressure of various >> > mount daemons or something like that. But at rest, it works >> > flawlessly. >> > >> > Maybe Alba Pompeo just faces an issue with wide filesystem tree that >> > needs to be inside chroot. >> >> I don't see why chroot is necessary at all. If you want a glibc >> environment for a single app you can put all the glibc stuff in its >> own library path and either invoke the binary manually using the glibc >> dynamic linker or have (a symlink to) the glibc dynamic linker in >> /lib. Then it can access the normal filesystem just fine. >> >> Containers (or just chroot) are of course preferable when you actually >> do want to isolate the program for trust/privilege purposes, but >> they're not a technical requirement for running foreign-libc binaries. >> >> Rich > > And glibc will not pickup random musl linked shared objects from > standard paths (/lib:/usr/lib) from host? To be honest, I did not even > tried just because I do not want to pollute my systems with glibc. > > -- > 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.