mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Рысь <lynx@lynxlynx.tk>
To: musl@lists.openwall.com
Subject: Re: musl & proprietary programs
Date: Thu, 24 Dec 2015 01:51:35 +0700	[thread overview]
Message-ID: <20151224015135.34dfe5f4@r2lynx> (raw)
In-Reply-To: <20151223174352.GA238@brightrain.aerifal.cx>

On Wed, 23 Dec 2015 12:43:52 -0500
Rich Felker <dalias@libc.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@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

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


  reply	other threads:[~2015-12-23 18:51 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-12-22 11:23 Alba Pompeo
2015-12-22 11:27 ` Timo Teras
2015-12-22 15:25   ` Рысь
2015-12-22 15:37     ` Alba Pompeo
2015-12-23 14:48       ` Szabolcs Nagy
2015-12-23 16:01         ` u-uy74
2015-12-23 17:22         ` Рысь
2015-12-23 17:43           ` Rich Felker
2015-12-23 18:51             ` Рысь [this message]
2015-12-23 20:00               ` Alba Pompeo
2015-12-24  5:04                 ` Рысь
2015-12-24  5:16                   ` Rich Felker
2015-12-24 10:40                     ` Szabolcs Nagy
2015-12-27  3:54                       ` Rich Felker
2015-12-24  7:00                 ` Isaac Dunham
2015-12-24 19:49                   ` Isaac Dunham
2015-12-24 21:29                     ` Alba Pompeo
2015-12-24  5:12               ` Rich Felker
2015-12-24  7:20                 ` Рысь

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20151224015135.34dfe5f4@r2lynx \
    --to=lynx@lynxlynx.tk \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).