From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/9007 Path: news.gmane.org!not-for-mail From: =?UTF-8?B?0KDRi9GB0Yw=?= Newsgroups: gmane.linux.lib.musl.general Subject: Re: musl & proprietary programs Date: Thu, 24 Dec 2015 14:20:19 +0700 Message-ID: <20151224142019.12039875@r2lynx> References: <20151222132706.57214aa6@vostro> <20151222222513.10f23f5a@r2lynx> <20151223144852.GR23362@port70.net> <20151224002205.588ac8e8@r2lynx> <20151223174352.GA238@brightrain.aerifal.cx> <20151224015135.34dfe5f4@r2lynx> <20151224051240.GB238@brightrain.aerifal.cx> 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 1450941548 5197 80.91.229.3 (24 Dec 2015 07:19:08 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 24 Dec 2015 07:19:08 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-9020-gllmg-musl=m.gmane.org@lists.openwall.com Thu Dec 24 08:19:07 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 1aC0B0-0005FO-SO for gllmg-musl@m.gmane.org; Thu, 24 Dec 2015 08:19:06 +0100 Original-Received: (qmail 22346 invoked by uid 550); 24 Dec 2015 07:19:05 -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 22314 invoked from network); 24 Dec 2015 07:19:04 -0000 X-Spam-Level: X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED,BAYES_00 autolearn=ham autolearn_force=no version=3.4.0 In-Reply-To: <20151224051240.GB238@brightrain.aerifal.cx> X-Mailer: claws Xref: news.gmane.org gmane.linux.lib.musl.general:9007 Archived-At: On Thu, 24 Dec 2015 00:12:40 -0500 Rich Felker wrote: > On Thu, Dec 24, 2015 at 01:51:35AM +0700, =D0=A0=D1=8B=D1=81=D1=8C wrote: > > On Wed, 23 Dec 2015 12:43:52 -0500 > > Rich Felker wrote: > >=20 > > > On Thu, Dec 24, 2015 at 12:22:05AM +0700, =D0=A0=D1=8B=D1=81=D1=8C wr= ote: > > > > On Wed, 23 Dec 2015 15:48:53 +0100 > > > > Szabolcs Nagy wrote: > > > >=20 > > > > > * 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. > > > > > >=20 > > > > >=20 > > > > > on x86, binaries linked against glibc can be made to work with > > > > > musl. > > > > >=20 > > > > > 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. > > > >=20 > > > > 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. > > > >=20 > > > > Maybe Alba Pompeo just faces an issue with wide filesystem tree > > > > that needs to be inside chroot. > > >=20 > > > 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. > > >=20 > > > 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. > >=20 > > 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. >=20 > 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. >=20 > 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. --=20 http://lynxlynx.tk/ Power electronics made simple Unix and simple KISS C code