[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 24 Dec 2015 00:12:40 -0500
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: musl & proprietary programs
On Thu, Dec 24, 2015 at 01:51:35AM +0700, Рысь 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.
>
> 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.
glibc's dynamic linker gets its library paths from ld.so.conf which is
in $sysconfdir. If you build your own glibc you can set that to
something other than /etc, or you can just be content with it living
in /etc since musl does not use it. I'm not 100% sure it doesn't also
have built-in default paths that aren't replaced by ld.so.conf, but if
it does, those will be suppressed by building your own glibc with a
different $prefix.
Rich
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.
