From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/9001 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: musl & proprietary programs Date: Thu, 24 Dec 2015 00:12:40 -0500 Message-ID: <20151224051240.GB238@brightrain.aerifal.cx> References: <20151222132706.57214aa6@vostro> <20151222222513.10f23f5a@r2lynx> <20151223144852.GR23362@port70.net> <20151224002205.588ac8e8@r2lynx> <20151223174352.GA238@brightrain.aerifal.cx> <20151224015135.34dfe5f4@r2lynx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1450933978 972 80.91.229.3 (24 Dec 2015 05:12:58 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 24 Dec 2015 05:12:58 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-9014-gllmg-musl=m.gmane.org@lists.openwall.com Thu Dec 24 06:12:58 2015 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1aByCv-0004Aj-70 for gllmg-musl@m.gmane.org; Thu, 24 Dec 2015 06:12:57 +0100 Original-Received: (qmail 16168 invoked by uid 550); 24 Dec 2015 05:12:54 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 16150 invoked from network); 24 Dec 2015 05:12:53 -0000 Content-Disposition: inline In-Reply-To: <20151224015135.34dfe5f4@r2lynx> User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:9001 Archived-At: On Thu, Dec 24, 2015 at 01:51:35AM +0700, Рысь wrote: > On Wed, 23 Dec 2015 12:43:52 -0500 > Rich Felker wrote: > > > On Thu, Dec 24, 2015 at 12:22:05AM +0700, Рысь wrote: > > > On Wed, 23 Dec 2015 15:48:53 +0100 > > > Szabolcs Nagy wrote: > > > > > > > * Alba Pompeo [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