[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20151224142019.12039875@r2lynx>
Date: Thu, 24 Dec 2015 14:20:19 +0700
From: Рысь <lynx@...xlynx.tk>
To: musl@...ts.openwall.com
Subject: Re: musl & proprietary programs
On Thu, 24 Dec 2015 00:12:40 -0500
Rich Felker <dalias@...c.org> wrote:
> 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
Just did experimented with fresh chroot.
glibc indeed picks up libs from prefix where you'd put it and nowhere
from if you said so in ld.so.conf.
Unprefixed glibc (for example, taken from glibc system)
requires /lib/ld*.so, /etc/ld.so.conf, /etc/ld.so.cache (generated by
glibc's ldconfig, not necessary be put into /sbin) and that's counted
by me as "being polluted with glibc" :-)
But even if glibc works, there is still problem with embedded paths
inside applications. Certain cases require hard debugging them with
strace. Many can set RPATH into elf directly and you will end up
hacking glibc not to load libs from RPATH. I do not remember exact
details, but that temporary X server in chroot was the huge case of
complex dlopen logic.
So I use chroot just to avoid this complexity.
--
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.
