From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/8998 Path: news.gmane.org!not-for-mail From: Alba Pompeo Newsgroups: gmane.linux.lib.musl.general Subject: Re: musl & proprietary programs Date: Wed, 23 Dec 2015 18:00:12 -0200 Message-ID: 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: quoted-printable X-Trace: ger.gmane.org 1450900829 20633 80.91.229.3 (23 Dec 2015 20:00:29 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 23 Dec 2015 20:00:29 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-9011-gllmg-musl=m.gmane.org@lists.openwall.com Wed Dec 23 21:00:29 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 1aBpaF-00083b-4y for gllmg-musl@m.gmane.org; Wed, 23 Dec 2015 21:00:27 +0100 Original-Received: (qmail 22267 invoked by uid 550); 23 Dec 2015 20:00:24 -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 22248 invoked from network); 23 Dec 2015 20:00:23 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; bh=TkLMSo3fgdH0HExVDTtiD1fM6mFhPYGMINHMYqcGd54=; b=T6KE0Ta4SMj8T5uzUcd36XYm9QXUEndL22DkIYCFU2e/bspYgDDBorW8C2o+HzYVUK l98LANnhZ0OKhHOK2q0VuoGLjVmkJbWEoem0CSer8kgtGGSUfmiZW/14pewe2X1CVH0R zgtso766OIz9Gx0kgl+7bUI1D89tBTMA9vkog5xsrzy7r7P+OkbRX/R43DHN5GeyeADC GjR3PKu4ixe1TxkkPyLBJJIqNlMBwv1nXRlkosXAjAy0zkShC/juKnCi0MK7rGa25ZrW 7NfH8Mr+nerJ8SzL3RWCkZ6ji9tOcogRX0uLo5aqp4gdVKUpFgkqPHeQ780ttVjwhVeB XZLg== X-Received: by 10.28.223.134 with SMTP id w128mr24149598wmg.69.1450900812444; Wed, 23 Dec 2015 12:00:12 -0800 (PST) In-Reply-To: <20151224015135.34dfe5f4@r2lynx> Xref: news.gmane.org gmane.linux.lib.musl.general:8998 Archived-At: I also don't want to pollute my system with glibc. That's why I asked if there was any plan to improve musl support of proprietary programs like the ones I listed. But as a last resort, I think Rich's method is the best so far, but I'm a bit lost on the details since I'm not a libc expert. I couldn't find a wiki page detailing Rich's method on Void or Alpine (the 2 distros I know use musl). Is there a step-by-step for a novice somewhere? On Wed, Dec 23, 2015 at 4:51 PM, =D0=A0=D1=8B=D1=81=D1=8C wrote: > On Wed, 23 Dec 2015 12:43:52 -0500 > Rich Felker wrote: > >> On Thu, Dec 24, 2015 at 12:22:05AM +0700, =D0=A0=D1=8B=D1=81=D1=8C 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. >> >> 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