Re: Will musl work as a lsb alternative? (was Re: [musl] re: musl setup attempt)

[Rich Felker <dalias@aerifal.cx>]

On Tue, Mar 26, 2013 at 09:02:29AM -0400, LM wrote:
> On 3/14/13, Szabolcs Nagy <nsz@port70.net> wrote:
> > if exec fails then something is wrong before the application
> > starts, maybe you can see what happens if you strace the
> > loader, which you can do by
> >
> >  strace path/to/libc.so wavpack
> 
> Thanks for the suggestion.  Found the problem.  Bad link during
> installation.  It's working fine now.
> 
> I've built some applications with musl and so far, it's working really
> well.  What I'm really curious about and one of the reasons I wanted
> to try musl out was that I was wondering if it could be used to do
> some of the things lsb proponents say lsb (Linux Systems Base) can do.

Yes and no.

>  Specifically, I'd like to be able to build applications with the
> compiler and have them work if I take them to any ix86 system.  So, if
> I built the applications on a Debian system, I'd like to be able to
> still run them on a Red Hat system or OpenSuse or Slackware, etc. as
> long as the system uses the same type of processor.

In principle, the binary should not depend on the distro it was built
on/for. musl is better-equipped to give this property than glibc,
since linking with glibc introduces a lot of symbol version issues
that make it impossible to use the binary on a system with even
slightly-older glibc, even if the older glibc, in principle, has
everything it should need to run the binary.

In practice, the other areas where distros differ heavily are:

- which options/optional-dependencies they build various third-party
  libraries with.

- where they store files belonging to various libraries/packages.

If you're building apps against musl, then you're _probably_ not going
to be using the existing library files installed by your distro unless
it's a musl-based distro. You might be able to get them to work, but
the main point of the partial ABI-compatibility is to allow use of
"important" libraries for which you don't have source, not to allow
use of the full existing ecosystem of glibc-linked libraries a distro
might have. The latter may eventually be possible, but aiming for it
is a lot of work with diminishing benefits..

> Am also wondering
> if it would be necessary to build everything statically or whether it
> would work dynamically if all required libraries were available on the
> target system.  Another option might be to build an application with
> the C library linked in statically and the rest of the libraries
> dynamic.  Still looking into pros and cons for the various options.

There's presently no support for static linking libc but still using
dynamic linking. Adding support is not impossible, but also not easy.
Anyway, for what you're talking about, it's really not necessary. Full
dynamic linking will work, but you probably want to be providing the
libraries.

> If this sounds feasible, my next question is about building musl to
> handle C++.  I read in the list archives that there was a successful
> C++ build.  I also read this can't be done as a wrapper.  Found the
> list of cross-compilers at (

See Gregor's musl-cross repository. It contains the gcc patches and
build scripts to get a compiler with C++ support targetting musl. This
works for building native compilers too. If you get stuck, feel free
to ask for help on the IRC channel; it's very active.

> http://wiki.musl-libc.org/wiki/Getting_started ) and was thinking the
> crossx86-i486-linux-musl-0.9.9.tar.xz might do the trick.  However,
> are there any instructions for building the cross-compilers and the
> C++ implementation like there are for the install information?  Would
> like to try to build the C/C++ cross-compilers from source.  Am hoping
> they can coexist with my current gnu C/C++ compiler on my Debian
> system the way the lsb compilers coexist with it.

Yes, just install them in their own location.

> Any suggestions, recommendations?  Would I be better off sticking with
> lsb or will musl do the job as well?  Thanks for the help.

Could you elaborate on what you mean by "sticking with LSB"? LSB is a
specification for ABI, filesystem layout, etc. -- basically, what apps
can expect from a "Linux system" -- not really a tool in itself.

Rich