Re: musl & proprietary programs

[Rich Felker <dalias@libc.org>]

On Thu, Dec 24, 2015 at 12:22:05AM +0700, Рысь wrote:
> On Wed, 23 Dec 2015 15:48:53 +0100
> Szabolcs Nagy <nsz@port70.net> wrote:
> 
> > * Alba Pompeo <albapompeo@gmail.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