Re: musl & proprietary programs

[Alba Pompeo <albapompeo@gmail.com>]

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, Рысь <lynx@lynxlynx.tk> wrote:
> 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