musl & proprietary programs

musl & proprietary programs

[Alba Pompeo]

'Morning developers,

As a user, my main issue with musl by far is the lack of ability to
run proprietary programs. Almost all software I need for work is
proprietary and I currently have to dual boot other operating system
just to run it, because there is no musl binary.

Is there any strategy to get musl to be more useful on proprietary
environments? Either partnerships with some companies to spread musl
or a compatibility mode that you can use when needed? This would be of
great help for those that unfortunately aren't on the ideal world
where every tool has the source available for you to compile.

Ciao.

Re: musl & proprietary programs

[Timo Teras]

On Tue, 22 Dec 2015 09:23:08 -0200
Alba Pompeo <albapompeo@gmail.com> wrote:

> As a user, my main issue with musl by far is the lack of ability to
> run proprietary programs. Almost all software I need for work is
> proprietary and I currently have to dual boot other operating system
> just to run it, because there is no musl binary.
> 
> Is there any strategy to get musl to be more useful on proprietary
> environments? Either partnerships with some companies to spread musl
> or a compatibility mode that you can use when needed? This would be of
> great help for those that unfortunately aren't on the ideal world
> where every tool has the source available for you to compile.

Musl works with surprisingly many proprietary programs. Could you
explain more the problem you have?

Though, you you do have to have symlinks for the glibc style library
names for things to work.

In Alpine Linux these comes with "apk add libc6-compat".

/Timo

Re: musl & proprietary programs

[Рысь]

On Tue, 22 Dec 2015 13:27:06 +0200
Timo Teras <timo.teras@iki.fi> wrote:

> On Tue, 22 Dec 2015 09:23:08 -0200
> Alba Pompeo <albapompeo@gmail.com> wrote:
> 
> > As a user, my main issue with musl by far is the lack of ability to
> > run proprietary programs. Almost all software I need for work is
> > proprietary and I currently have to dual boot other operating system
> > just to run it, because there is no musl binary.
> > 
> > Is there any strategy to get musl to be more useful on proprietary
> > environments? Either partnerships with some companies to spread musl
> > or a compatibility mode that you can use when needed? This would be
> > of great help for those that unfortunately aren't on the ideal world
> > where every tool has the source available for you to compile.
> 
> Musl works with surprisingly many proprietary programs. Could you
> explain more the problem you have?
> 
> Though, you you do have to have symlinks for the glibc style library
> names for things to work.
> 
> In Alpine Linux these comes with "apk add libc6-compat".
> 
> /Timo

I can also suggest building chroots from existing glibc distributions.
For example, one can get full Slackware DVD, unpack it fully or
partially and use the result root as chroot tree and put a program
inside it. Though there is little help needed to define proper symlinks
to unpacked shared objects. This can be achieved with simple script
employing readelf or running glibc's ldconfig inside chroot.

This method is IMO more cleaner when you want to run glibc programs
completely unmodified. Missing virtual filesystems and locations with
user data can be bind-mounted.

-- 
http://lynxlynx.tk/
Power electronics made simple
Unix and simple KISS C code

Re: musl & proprietary programs

[Alba Pompeo]

chroot is a little better than dual-boot, but still very unfriendly
for a day-to-day usage of many proprietary tools.


On Tue, Dec 22, 2015 at 1:25 PM, Рысь <lynx@lynxlynx.tk> wrote:
> On Tue, 22 Dec 2015 13:27:06 +0200
> Timo Teras <timo.teras@iki.fi> wrote:
>
>> On Tue, 22 Dec 2015 09:23:08 -0200
>> Alba Pompeo <albapompeo@gmail.com> wrote:
>>
>> > As a user, my main issue with musl by far is the lack of ability to
>> > run proprietary programs. Almost all software I need for work is
>> > proprietary and I currently have to dual boot other operating system
>> > just to run it, because there is no musl binary.
>> >
>> > Is there any strategy to get musl to be more useful on proprietary
>> > environments? Either partnerships with some companies to spread musl
>> > or a compatibility mode that you can use when needed? This would be
>> > of great help for those that unfortunately aren't on the ideal world
>> > where every tool has the source available for you to compile.
>>
>> Musl works with surprisingly many proprietary programs. Could you
>> explain more the problem you have?
>>
>> Though, you you do have to have symlinks for the glibc style library
>> names for things to work.
>>
>> In Alpine Linux these comes with "apk add libc6-compat".
>>
>> /Timo
>
> I can also suggest building chroots from existing glibc distributions.
> For example, one can get full Slackware DVD, unpack it fully or
> partially and use the result root as chroot tree and put a program
> inside it. Though there is little help needed to define proper symlinks
> to unpacked shared objects. This can be achieved with simple script
> employing readelf or running glibc's ldconfig inside chroot.
>
> This method is IMO more cleaner when you want to run glibc programs
> completely unmodified. Missing virtual filesystems and locations with
> user data can be bind-mounted.
>
> --
> http://lynxlynx.tk/
> Power electronics made simple
> Unix and simple KISS C code

Re: musl & proprietary programs

[Szabolcs Nagy]

* 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.

Re: musl & proprietary programs

[u-uy74]

On Wed, Dec 23, 2015 at 03:48:53PM +0100, Szabolcs Nagy 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.

Proot comes to mind (http://proot.me/) which looks like just
the right tool for the purpose.

Rune

Re: musl & proprietary programs

[Рысь]

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.

-- 
http://lynxlynx.tk/
Power electronics made simple
Unix and simple KISS C code

Re: musl & proprietary programs

[Rich Felker]

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

Re: musl & proprietary programs

[Рысь]

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

Re: musl & proprietary programs

[Alba Pompeo]

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

Re: musl & proprietary programs

[Рысь]

On Wed, 23 Dec 2015 18:00:12 -0200
Alba Pompeo <albapompeo@gmail.com> wrote:

> 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?

There is also problem that musl wishes not to be fully glibc compat.
Certain libc structs and public structs coming from glibc headers that
are not required to be ABI same will be different on musl for
performance or optimization reasons, and programs relying on them
usually will not be happy. Simple programs probably still will work.

I tried to hack into this area back in 0.9.x times (Jul2012). I even got
userspace nvidia libraries being loaded by plain musl into `glxgears`
and it did worked. Last time I revisited that was in Jan2015, and musl
was greatly "improved" - applying same changes then trying to run the
same `glxgears` resulted in plain segfault. From Jan2015 I was running
X server in chroot, and completely moved to nouveau by Mar2015.

Software that loads many-many shared objects, including modern GUI libs
will BE unhappy. Just because when building with glibc result binaries
are much polluted with glibcisms. My case was simpler.

-- 
http://lynxlynx.tk/
Power electronics made simple
Unix and simple KISS C code

Re: musl & proprietary programs

[Rich Felker]

On Thu, Dec 24, 2015 at 01:51:35AM +0700, Рысь 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.
> 
> 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

Re: musl & proprietary programs

[Rich Felker]

On Thu, Dec 24, 2015 at 12:04:42PM +0700, Рысь wrote:
> On Wed, 23 Dec 2015 18:00:12 -0200
> Alba Pompeo <albapompeo@gmail.com> wrote:
> 
> > 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?
> 
> There is also problem that musl wishes not to be fully glibc compat.
> Certain libc structs and public structs coming from glibc headers that
> are not required to be ABI same will be different on musl for
> performance or optimization reasons, and programs relying on them
> usually will not be happy. Simple programs probably still will work.

There are no differences for performance or optimization reasons,
unless you want to count [u]int_fastNN_t which are basically never
used in public APIs anyway. Otherwise the only differences are that
musl lacks the 32-bit-off_t structures on 32-bit archs (i.e. it can't
match the _FILE_OFFSET_BITS=32 ABI on glibc, but it's not safe to use
this ABI anymore anyway) and that musl does not copy the
non-conforming, unsafe-because-it's-too-small glibc regoff_t on 64-bit
archs (this only affects regexec).

That's the situation for x86 and mainstream archs, at least. Some
other archs have additional differences due to further brokenness in
glibc (like IBM double-double on powerpc).

Rich

Re: musl & proprietary programs

[Isaac Dunham]

On Wed, Dec 23, 2015 at 06:00:12PM -0200, Alba Pompeo wrote:
> 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.

I looked through the thread and saw no list of proprietary programs.
(Is this undelivered mail? is google bouncing random emails?)

> 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?

I don't know of any step-by-step guide that covers what you're asking about,
but I have done it before. The important things:
* glibc uses paths configured in /etc/ld.so.conf, which these days
 usually just says "include /etc/ld.so.conf.d/*.conf".
 Those files, in turn, contain a newline-separated list of directories
 which are searched for libraries.
 musl uses /etc/ld-musl-$ARCH.path instead; this is a simple newline or
 colon separated list of directories.
* with Debian's default configuration, the directories which glibc searches
 are {/usr/,/}lib/linux-$CPU-gnu, and /usr/local/lib.
 Delete /etc/ld.so.conf.d/libc.conf, and the library directory structure
 will have no conflicts with musl.
* there are two possible approaches:
 - build a glibc chroot, drop a few links in /lib, put a few files in
   /etc, and you redirect glibc applications to the libraries in the
   chroot.
 - assemble a set of library packages, extract them, make sure there won't
   be conflicts, and copy it over into the root (so that you have both
   an Alpine install and a portion of a Debian install, with the same root)
   Only feasible with "multiarch-enabled" guest distros, meaning Debian and
   relatives.

For the "use a chroot" approach, you will probably want to do something
like this (assumes "guest" chroot in /opt/glibc-sys)
touch /etc/ld.so.nohwcap
sed -e 's|^/|/opt/glibc-sys/|' /opt/glibc-sys/etc/ld.so.conf.d/*.conf \
	>/etc/ld.so.conf

For the "parallel install" approach, I'd create a list of files that are
both the glibc library set and the host, sort through them to figure out
if they're needed/how to change them, and then do something like this
(from the root of wherever you've extracted the libs to):
rm ./etc/ld.so.conf.d/libc.conf
find ./ | grep -v -x -F -f ../glibc-alpine-dupes | cpio -p /
touch /etc/ld.so.nohwcap

(This assumes that the list of duplicates is in the format:
./etc/passwd
...)

HTH,
Isaac Dunham

Re: musl & proprietary programs

[Рысь]

On Thu, 24 Dec 2015 00:12:40 -0500
Rich Felker <dalias@libc.org> wrote:

> On Thu, Dec 24, 2015 at 01:51:35AM +0700, Рысь 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.
> > 
> > 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

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.

-- 
http://lynxlynx.tk/
Power electronics made simple
Unix and simple KISS C code

Re: musl & proprietary programs

[Szabolcs Nagy]

* Rich Felker <dalias@libc.org> [2015-12-24 00:16:25 -0500]:
> On Thu, Dec 24, 2015 at 12:04:42PM +0700, ???????? wrote:
> > There is also problem that musl wishes not to be fully glibc compat.
> > Certain libc structs and public structs coming from glibc headers that
> > are not required to be ABI same will be different on musl for
> > performance or optimization reasons, and programs relying on them
> > usually will not be happy. Simple programs probably still will work.
> 
> There are no differences for performance or optimization reasons,
> unless you want to count [u]int_fastNN_t which are basically never
> used in public APIs anyway. Otherwise the only differences are that
> musl lacks the 32-bit-off_t structures on 32-bit archs (i.e. it can't
> match the _FILE_OFFSET_BITS=32 ABI on glibc, but it's not safe to use
> this ABI anymore anyway) and that musl does not copy the
> non-conforming, unsafe-because-it's-too-small glibc regoff_t on 64-bit
> archs (this only affects regexec).
> 

thread cancellation cleanup abi is different too
(because glibc is broken for async-cancel)
but nobody uses that so it should not be a problem

the nvidia dso may segfault for many reasons, iirc
the last time we identified that it uses stdio in
a broken way, but there are numerous problems so
a crash should not be a surprise.

Re: musl & proprietary programs

[Isaac Dunham]

On Wed, Dec 23, 2015 at 11:00:51PM -0800, Isaac Dunham wrote:
> On Wed, Dec 23, 2015 at 06:00:12PM -0200, Alba Pompeo wrote:
> > 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.
> 
> I looked through the thread and saw no list of proprietary programs.
> (Is this undelivered mail? is google bouncing random emails?)

(Apparently didn't get successfully delivered from the list to me; thanks
 for sending a copy.)

Looking at AMPL's linux32 demo, I get this list of missing functions:
 __divdi3
 __fpu_control
 __isinf
 __isinfl
 __isnanl
 __strtod_internal
 fedisableexcept
 feenableexcept
 pthread_rwlockattr_setkind_np

The first indicates that it may be necessary to add libgcc_s.so.1 to
LD_PRELOAD.
The rest are missing from musl for ABI compat.
ampl and minos are "for GNU/Linux 2.2.5", so may use the 32-bit IO abi.
__is* can be trivially implemented.
__strtod_internal is a version of strtod with an extra int that's expected
to be 0 (per LSB); no idea what that's for.

HTH,
Isaac Dunham

Re: musl & proprietary programs

[Alba Pompeo]

Isaac, I just realized nobody on the mailing list received that copy I
sent you. It was delivered to just 1 person by my mistake.
Here's a copy to everyone.

Here's a list of some programs I couldn't get to work - in
alphabetical order and with links to those easily available (no
registration required for free trial).

AIMMS http://download.aimms.com/aimms/download/data/4.13/2.233/Aimms-4.13.2-233.x86_64.rpm
AMPL http://ampl.com/dl/demo/ampl-demo-linux64.tar.gz
MATLAB
Siemens NX
SPSS

It was a colleague that recommended me musl and I immediately loved it
after reading about its goals. But he forgot to tell me about these
shortcomings, which he has too. We both have to dual-boot to use most
proprietary software we need. Maybe we are doing something wrong?

I both thanked my colleague to have introduced me to musl and cursed
him for making my life harder :)
But in general I'm pleased to use musl now. I hope the proprietary
software I need works well.

For now I'd like to focus on AMPL. I got it to run on a chroot as per
my work colleague help, but Rich Felker's suggestions sounds much
better. But I'm out of luck by being a novice user. Does anyone know
of a guide for Void or Alpine (musl distributions) that explain it in
a step-by-step? I couldn't find any.

@Isaac
If it makes things easier, CPLEX can be used instead of MINOS. Does
that helps a bit?

Ciao.

On Thu, Dec 24, 2015 at 5:49 PM, Isaac Dunham <ibid.ag@gmail.com> wrote:
> On Wed, Dec 23, 2015 at 11:00:51PM -0800, Isaac Dunham wrote:
>> On Wed, Dec 23, 2015 at 06:00:12PM -0200, Alba Pompeo wrote:
>> > 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.
>>
>> I looked through the thread and saw no list of proprietary programs.
>> (Is this undelivered mail? is google bouncing random emails?)
>
> (Apparently didn't get successfully delivered from the list to me; thanks
>  for sending a copy.)
>
> Looking at AMPL's linux32 demo, I get this list of missing functions:
>  __divdi3
>  __fpu_control
>  __isinf
>  __isinfl
>  __isnanl
>  __strtod_internal
>  fedisableexcept
>  feenableexcept
>  pthread_rwlockattr_setkind_np
>
> The first indicates that it may be necessary to add libgcc_s.so.1 to
> LD_PRELOAD.
> The rest are missing from musl for ABI compat.
> ampl and minos are "for GNU/Linux 2.2.5", so may use the 32-bit IO abi.
> __is* can be trivially implemented.
> __strtod_internal is a version of strtod with an extra int that's expected
> to be 0 (per LSB); no idea what that's for.
>
> HTH,
> Isaac Dunham

Re: musl & proprietary programs

[Rich Felker]

On Thu, Dec 24, 2015 at 11:40:10AM +0100, Szabolcs Nagy wrote:
> * Rich Felker <dalias@libc.org> [2015-12-24 00:16:25 -0500]:
> > On Thu, Dec 24, 2015 at 12:04:42PM +0700, ???????? wrote:
> > > There is also problem that musl wishes not to be fully glibc compat.
> > > Certain libc structs and public structs coming from glibc headers that
> > > are not required to be ABI same will be different on musl for
> > > performance or optimization reasons, and programs relying on them
> > > usually will not be happy. Simple programs probably still will work.
> > 
> > There are no differences for performance or optimization reasons,
> > unless you want to count [u]int_fastNN_t which are basically never
> > used in public APIs anyway. Otherwise the only differences are that
> > musl lacks the 32-bit-off_t structures on 32-bit archs (i.e. it can't
> > match the _FILE_OFFSET_BITS=32 ABI on glibc, but it's not safe to use
> > this ABI anymore anyway) and that musl does not copy the
> > non-conforming, unsafe-because-it's-too-small glibc regoff_t on 64-bit
> > archs (this only affects regexec).
> 
> thread cancellation cleanup abi is different too
> (because glibc is broken for async-cancel)
> but nobody uses that so it should not be a problem

Indeed, I forgot about that because it's not a types difference. I'd
thought about possibly trying to support that too, but it looks hard
and not worth the effort (or other costs).

> the nvidia dso may segfault for many reasons, iirc
> the last time we identified that it uses stdio in
> a broken way, but there are numerous problems so
> a crash should not be a surprise.

Indeed, I think we found that it's assigning to stdout, which aside
from being utter nonsense (stdout is not even specified to be an
lvalue), happens to crash since musl's stdout is const and thus
usually in read-only/relro memory.

Rich