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

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

[LM]

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

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

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

Sincerely,
Laura

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

[Rich Felker]

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

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

[Isaac Dunham]

On Tue, 26 Mar 2013 19:03:28 -0400
Rich Felker <dalias@aerifal.cx> wrote:

> 
> > 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:
There is also a LSB toolchain (lsbcc, lsbc++, etc) meant to produce binaries that use the LSB ABI and are portable so you don't need to worry too much about glibc symbol versioning, etc. 

Laura:
If you don't want to ship any/many libraries and fully static binaries are not an option, using lsbcc is your only otion. That does require the target distro to provide LSB support, which is widespread but certainly not universal.
If you want binaries that can run _anywhere_, static linking with a generic build of musl will work well (x86 musl compiles for i486 by default, although you can change the minimum processor by setting CFLAGS to -march=...).  These will work to some degree as far back as 2.4.x distros (I tested on DSL), if you don't need threading or full POSIX conformance (2.4 did not have what's needed for full POSIX).  

uclibc static linking will do better if supporting 2.4.x or very early 2.6.x kernels is a high priority, though it's not fully POSIX conformant, LGPL (requires distributing application source code or object file so customers can relink), and slightly larger. Don't think about a uclibc shared binary if you want portability; that way lies madness.

Dynamically linked musl binaries are only going to work out-of-box on musl systems or for those who installed musl with the same syslibdir; 
it is possible to use the path/to/libc.so <command> trick or an ELF editor to circumvent this.  Currently, you might want to include most of the libraries if you go for this.

HTH, 
Isaac Dunham <idunham@lavabit.com>

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

[Rich Felker]

On Tue, Mar 26, 2013 at 06:40:37PM -0700, Isaac Dunham wrote:
> On Tue, 26 Mar 2013 19:03:28 -0400
> Rich Felker <dalias@aerifal.cx> wrote:
> 
> > 
> > > 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:
> There is also a LSB toolchain (lsbcc, lsbc++, etc) meant to produce
> binaries that use the LSB ABI and are portable so you don't need to
> worry too much about glibc symbol versioning, etc.

Ah, nice. I was unaware of this.

> If you want binaries that can run _anywhere_, static linking with a
> generic build of musl will work well (x86 musl compiles for i486 by
> default, although you can change the minimum processor by setting
> CFLAGS to -march=...).

Note that real i386 is not supported nor supportable unless your
kernel goes out of the way to support it (emulating cmpxchg), and
support for the original i386 was recently removed from the kernel. So
I don't think there's any additional compatibility to be had here.

> These will work to some degree as far back as
> 2.4.x distros (I tested on DSL), if you don't need threading or full
> POSIX conformance (2.4 did not have what's needed for full POSIX).
>
> uclibc static linking will do better if supporting 2.4.x or very
> early 2.6.x kernels is a high priority, though it's not fully POSIX
> conformant, LGPL (requires distributing application source code or
> object file so customers can relink), and slightly larger. Don't
> think about a uclibc shared binary if you want portability; that way
> lies madness.

Basically, the issue is that threads are not possible pre-2.6; uClibc
gets around this by using the ancient LinuxThreads implementation,
which basically just creates a swarm of processes that happen to share
memory and calls them threads.

If you don't need threads or new (mainly POSIX-2008) features, musl
should work even on 2.4 kernels. Of course, 2.4 kernels have a number
of bugs and conformance issues, especially in signal handling, which
apply regardless of which libc you are using.

> Dynamically linked musl binaries are only going to work out-of-box
> on musl systems or for those who installed musl with the same
> syslibdir;

As long as you can install the musl dynamic linker in /lib, and a path
configuration file in /etc, this should not be a problem.

I think it would still be a very interesting exercise to make some
tools to put ld-musl.so inside the program binary, so that you could
have a binary that does not depend on any particular dynamic linker
path.

> it is possible to use the path/to/libc.so <command> trick or an ELF
> editor to circumvent this. Currently, you might want to include most
> of the libraries if you go for this.

Yes, you could definitely do this with a shell script wrapper too. It
would work a lot better if we added command line options to the
dynamic linker, so that you could do something like:

exec /opt/myapp/bin/ld-musl-$(ARCH).so.1 --libpath /opt/myapp/lib -- \
  /opt/myapp/bin/myapp "$@"

Note that the current ld-musl already accepts "--" on the command line
like this, in anticipation of such enhancements.

Rich

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

[Rob Landley]

On 03/26/2013 08:40:37 PM, Isaac Dunham wrote:
> On Tue, 26 Mar 2013 19:03:28 -0400
> Rich Felker <dalias@aerifal.cx> wrote:
> 
> >
> > > 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:
> There is also a LSB toolchain (lsbcc, lsbc++, etc) meant to produce  
> binaries that
> use the LSB ABI and are portable so you don't need to worry too much  
> about glibc
> symbol versioning, etc.

Note that The Linux Standard base is a project of The Linux Foundation,  
which is
to Linux development what AOL was to the Internet. So expecting them to  
define
what is and isn't Linux is like Facebook saying "Blogs! Yes, that's a  
thing I
own, here's all you'll ever need to know about blogs and none of it  
will ever
live anywhere but facebook.com because I am the whole of the internet."

> Laura:
> If you don't want to ship any/many libraries and fully static  
> binaries are not an
> option, using lsbcc is your only otion. That does require the target  
> distro to
> provide LSB support, which is widespread but certainly not universal.

I note that static linking binaries doesn't have significant downsides
if you use sane libraries.

For many years glibc's maintainer had very strong opinions that weren't
necessarily supported by facts, but he's no longer maintainer (he left  
to
working at The Bank of Evil from "Despicable Me"), and nobody else has
a problem with it.

The size penalty using something like uClibc or musl is fairly small,  
and
the need to dlopen() things to make network resolution work are glibc  
bugs
that don't apply to other C libraries.

> If you want binaries that can run _anywhere_, static linking with a  
> generic
> build of musl will work well (x86 musl compiles for i486 by default,  
> although
> you can change the minimum processor by setting CFLAGS to  
> -march=...).  These
> will work to some degree as far back as 2.4.x distros (I tested on  
> DSL), if
> you don't need threading or full POSIX conformance (2.4 did not have  
> what's
> needed for full POSIX).

This is actually _more_ portable than static linking against glibc, due  
to their
symbol versioning issues.

> uclibc static linking will do better if supporting 2.4.x or very  
> early 2.6.x
> kernels is a high priority, though it's not fully POSIX conformant,  
> LGPL
> (requires distributing application source code or object file so  
> customers
> can relink), and slightly larger. Don't think about a uclibc shared  
> binary
> if you want portability; that way lies madness.

I have prebuilt uClibc toolchains at http://landley.net/aboriginal/bin  
(the
cross-compiler-$ARCH.tar.bz2 files) if you want to try that. Add the  
"bin"
subdirectory of that tarball to your $PATH and use CROSS_COMPILE=$ARCH-  
as
your prefix (and yes you need the trailing dash on the prefix name or  
it'll
try to use i686cc instead of i686-cc).

> Dynamically linked musl binaries are only going to work out-of-box on  
> musl
> systems or for those who installed musl with the same syslibdir;
> it is possible to use the path/to/libc.so <command> trick or an ELF  
> editor
> to circumvent this.  Currently, you might want to include most of the
> libraries if you go for this.

Doing so is totally not worth it. If you put together a distro that  
uses musl,
distributing musl shared binaries makes sense. Otherwise, static  
linking is
not a bad thing. If people tell you it is, they probably got bad (stale)
advice from the ex-glibc maintainer.

Really: significant effort to avoid static linking -- not worth it.

Rob

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

[LM]

On 3/26/13, Isaac Dunham wrote:
> On Tue, 26 Mar 2013 19:03:28 -0400
> Rich Felker wrote:
>> 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:
> There is also a LSB toolchain (lsbcc, lsbc++, etc) meant to produce binaries
> that use the LSB ABI and are portable so you don't need to worry too much
> about glibc symbol versioning, etc.

That was what I was referring to, using the lsbcc, lsbc++ compilers.

Isaac Dunham wrote:
> If you don't want to ship any/many libraries and fully static binaries are
> not an option, using lsbcc is your only option. That does require the target
> distro to provide LSB support, which is widespread but certainly not
> universal.

Have no problem with including the libraries.

> If you want binaries that can run _anywhere_, static linking with a generic
> build of musl will work well (x86 musl compiles for i486 by default,
> although you can change the minimum processor by setting CFLAGS to
> -march=...).

i486 default should be fine for my needs.  Target systems will most
likely be i486 and up.

Rich Felker wrote:
> If you don't need threads or new (mainly POSIX-2008) features, musl
> should work even on 2.4 kernels. Of course, 2.4 kernels have a number
> of bugs and conformance issues, especially in signal handling, which
>apply regardless of which libc you are using.

Thanks.  Will keep this in mind.

Isaac Dunham wrote:
> LGPL (requires distributing application source code or object file so customers
> can relink), and slightly larger. Don't think about a uclibc shared binary
> if you want portability; that way lies madness.

The project I'm working on will include source code for all Open
Source applications in it.  I'm trying to work out a way to do
something like OpenDisc's educational CD and offer a Linux version
with lightweight Open Source applications.  Was hoping to avoid
shipping a whole Linux distribution (live CD) just to try out using
the programs.  If the programs don't work on a particular system,
someone could always rebuild from source if necessary.  Most (but not
all) users seem to prefer having the binary, not just the source code.
 Not everyone wants to build everything from scratch just to try it
out.  Was thinking of setting the applications up to work somewhere
under the home directory so administrative rights would not be as big
of an issue.

>> it is possible to use the path/to/libc.so <command> trick or an ELF
>> editor to circumvent this. Currently, you might want to include most
>> of the libraries if you go for this.
>Yes, you could definitely do this with a shell script wrapper too. It
>would work a lot better if we added command line options to the
>dynamic linker...

I was thinking about that as a possibility.  Definitely sounds like
I'll need all the libraries.  The applications are mainly command
line, SDL, FLTK and curses based.  Command line and curses shouldn't
be a problem.  SDL has a DirectFB option which may work for some
users.  FLTK usually requires X Windows (although there's an older
version that has a port to DirectFB that might be worth
investigating).  Am wondering if I can build the X libraries from
scratch with musl, if they'll interact with the host system's X server
or if a user would need to exit their X server and use a musl built X
server and X libraries.

PCBSD does some packaging (on the style of a wrapper script) where
they set things like LD_LIBRARY_PATH before running the application
and reset it back to a default environment after the application runs.
 Was thinking if I can avoid the rpath switch when building the
applications, I might be able to make use of a technique similar to
that.

Rich Felker wrote:
>I think it would still be a very interesting exercise to make some
>tools to put ld-musl.so inside the program binary, so that you could
>have a binary that does not depend on any particular dynamic linker
>path.

That sounds like a very interesting idea.

Thanks to both of you.  You've given me a lot to think about and start
experimenting with.

Sincerely,
Laura
http://www.distasis.com/cpp/

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

[LM]

On 3/27/13, Rob Landley <rob@landley.net> wrote:
> The size penalty using something like uClibc or musl is fairly small,
> and
> the need to dlopen() things to make network resolution work are glibc
> bugs
> that don't apply to other C libraries.

That is one thing I really like about the glibc alternatives.

> I have prebuilt uClibc toolchains at http://landley.net/aboriginal/bin
> (the
> cross-compiler-$ARCH.tar.bz2 files) if you want to try that. Add the
> "bin"
> subdirectory of that tarball to your $PATH and use CROSS_COMPILE=$ARCH-
> as
> your prefix (and yes you need the trailing dash on the prefix name or
> it'll
> try to use i686cc instead of i686-cc).

Think I'll give things a try with musl first.  (I really like the
friendly licensing with musl.)  Even though I intend to supply all
source code for the project I'm working on, my personal preference is
toward MIT and BSD licensing over LGPL and GPL when it's available.  I
have done some building of source with uClibc in the past and I
appreciate your mentioning it in this context.  That does give a third
alternative (besides musl and lsbcc/lsbc++).  Thank you very much for
the link to the toolchain.

> Really: significant effort to avoid static linking -- not worth it.

Sta.li has a great article on this ( http://sta.li/faq ) that I really
like.  It was definitely one of the options I was considering for my
project.

Thanks for the comments and suggestions.

Sincerely,
Laura

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

[R P Herrold]

On Tue, 26 Mar 2013, Rich Felker wrote:

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

Actually, (putting on my LSB hat, being a participant in the 
weekly call for many years) the LSB also ships a tool kit to 
verify that needed interfaces are exposed and so forth.  It 
has sample LSB conformant applications that are build as part 
of the test harness process

It can be grafted into a buildbot, and deviations from 
conformance readily identified
 	http://www.linuxbase.org/buildbot/builders/

Joining the LSB working group is as easy as joining the call 
and participating.  I have a monthly post with more details in 
our minutes.  For more info see the bottom of the email at:
 	http://lists.linuxfoundation.org/pipermail/lsb-discuss/2013-February/007560.html

which lists many of those ways to participate

-- Russ herrold

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

[Kurt H Maier]

On Wed, Mar 27, 2013 at 12:21:13PM -0400, R P Herrold wrote:
> On Tue, 26 Mar 2013, Rich Felker wrote:
> 
> > 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.
> 
> Actually, (putting on my LSB hat, being a participant in the 
> weekly call for many years) the LSB also ships a tool kit to 
> verify that needed interfaces are exposed and so forth.  It 
> has sample LSB conformant applications that are build as part 
> of the test harness process
> 
> It can be grafted into a buildbot, and deviations from 
> conformance readily identified
>  	http://www.linuxbase.org/buildbot/builders/
> 
> Joining the LSB working group is as easy as joining the call 
> and participating.  I have a monthly post with more details in 
> our minutes.  For more info see the bottom of the email at:
>  	http://lists.linuxfoundation.org/pipermail/lsb-discuss/2013-February/007560.html
> 
> which lists many of those ways to participate
> 
> -- Russ herrold

Glancing at this wiki, I see things like "libQtSvg ... mandatory since
3.2" and it makes me not want to have anything to do with the LSB.

khm

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

[Isaac Dunham]

On Wed, 27 Mar 2013 10:23:46 -0400
LM <lmemsm@gmail.com> wrote:

> FLTK usually requires X Windows (although there's an older
> version that has a port to DirectFB that might be worth
> investigating).  Am wondering if I can build the X libraries from
> scratch with musl, if they'll interact with the host system's X server
> or if a user would need to exit their X server and use a musl built X
> server and X libraries.

You can build the X libraries against musl; you might want to pass 
--target=i486-linux-gnu since autoconf sometimes thinks it's dealing with libc5.

FYI, there is a project called tinyxlib based on a mix of work from xwoaf, Amigo Linux, one or two Puppy developers, and some other sources; I have a git repo for working on it at 
github.com/idunham/tinyxlib
It's not full-featured or complete, but there's enough to build several applications, it's small, and it only takes a couple minutes to build the commonly-used libs, so you might be interestin in trying it. Edit standard_definitions.mk to suit your site.
Of course, you will need a C++ compiler to do anything with FLTK.

X is called a "server" for a reason: assuming you don't have incompatible extensions, you can use any x server and any application you want as long as they can connect.  For example, you can:
-run musl and libc5 X apps with glibc X servers
-have IRIX, BSD, or Solaris apps running remotely and displaying locally on a glibc-based Linux system

HTH,
Isaac Dunham <idunham@lavabit.com>

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

[Rob Landley]

On 03/26/2013 10:20:32 PM, Rich Felker wrote:
> On Tue, Mar 26, 2013 at 06:40:37PM -0700, Isaac Dunham wrote:
> > On Tue, 26 Mar 2013 19:03:28 -0400
> > Rich Felker <dalias@aerifal.cx> wrote:
> > If you want binaries that can run _anywhere_, static linking with a
> > generic build of musl will work well (x86 musl compiles for i486 by
> > default, although you can change the minimum processor by setting
> > CFLAGS to -march=...).
> 
> Note that real i386 is not supported nor supportable unless your
> kernel goes out of the way to support it (emulating cmpxchg), and
> support for the original i386 was recently removed from the kernel. So
> I don't think there's any additional compatibility to be had here.
> 
> > These will work to some degree as far back as
> > 2.4.x distros (I tested on DSL), if you don't need threading or full
> > POSIX conformance (2.4 did not have what's needed for full POSIX).
> >
> > uclibc static linking will do better if supporting 2.4.x or very
> > early 2.6.x kernels is a high priority, though it's not fully POSIX
> > conformant, LGPL (requires distributing application source code or
> > object file so customers can relink), and slightly larger. Don't
> > think about a uclibc shared binary if you want portability; that way
> > lies madness.
> 
> Basically, the issue is that threads are not possible pre-2.6; uClibc
> gets around this by using the ancient LinuxThreads implementation,
> which basically just creates a swarm of processes that happen to share
> memory and calls them threads.
> 
> If you don't need threads or new (mainly POSIX-2008) features, musl
> should work even on 2.4 kernels. Of course, 2.4 kernels have a number
> of bugs and conformance issues, especially in signal handling, which
> apply regardless of which libc you are using.

It seems like there's a web page to be had out of this. Possibly FAQ  
updates?

> > Dynamically linked musl binaries are only going to work out-of-box
> > on musl systems or for those who installed musl with the same
> > syslibdir;
> 
> As long as you can install the musl dynamic linker in /lib, and a path
> configuration file in /etc, this should not be a problem.
> 
> I think it would still be a very interesting exercise to make some
> tools to put ld-musl.so inside the program binary, so that you could
> have a binary that does not depend on any particular dynamic linker
> path.

How does this differ from static linking?

Or do you mean a _compiler_ containing its own libc? And headers. And  
crt*.o. And libgcc.a. And a libz.so.1 that links to musl instead of  
libc.so.6. And...

> > it is possible to use the path/to/libc.so <command> trick or an ELF
> > editor to circumvent this. Currently, you might want to include most
> > of the libraries if you go for this.
> 
> Yes, you could definitely do this with a shell script wrapper too. It
> would work a lot better if we added command line options to the
> dynamic linker, so that you could do something like:
> 
> exec /opt/myapp/bin/ld-musl-$(ARCH).so.1 --libpath /opt/myapp/lib -- \
>   /opt/myapp/bin/myapp "$@"

You're aware that other C libraries let you switch this off because it  
renders the noexec flag to mount completely useless, right? Or did you  
have a fix for that?

Rob

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

[LM]

On Wed, Mar 27, 2013 at 6:14 PM, Isaac Dunham <idunham@lavabit.com> wrote:
> FYI, there is a project called tinyxlib based on a mix of work from xwoaf, Amigo Linux, one or two Puppy developers, and some other sources; I have a git repo for working on it at
> github.com/idunham/tinyxlib

I did run across the source for that recently.  I've also been looking
at the source for XMing and the Syllable forum has a thread on how far
they got trying to build Kdrive XSDL (
http://forum.syllable.org/viewtopic.php?t=1991 ).  I also saw some
posts on the Puppy forum about trying to compile X with musl that were
interesting.  Another thing I've been experimenting with is nano-x.
That works fine with FLTK 1.3.  Would have to see how well it builds
with musl.

I do have a series of scripts I put together for building an X Server
that I'm hoping to test out with musl and see how far I get and where
I need patching.  If that doesn't work, I'll back up and try some of
the other options like tinyxlib and possibly nano-x.  Thanks for
mentioning the tinyxlib project.

> Of course, you will need a C++ compiler to do anything with FLTK.

I'm going to need a C++ compiler for several things I want to build,
so that's definitely a must on my list.

> X is called a "server" for a reason: assuming you don't have incompatible extensions, you can use any x server and any application you want as long as they can connect.  For example, you can:
> -run musl and libc5 X apps with glibc X servers
> -have IRIX, BSD, or Solaris apps running remotely and displaying locally on a glibc-based Linux system

I thought that was the case, but just wanted to make sure I wasn't
missing any hidden gotcha's.  Thanks for the confirmation on that.
When I was reading about glibc, I was surprised to read that even if
you tell it to compile statically, it still pulled in dynamic
libraries.  Just wanted to make sure I wasn't missing something like
that with the X libraries.  Am not very familiar with the X Consortium
code and am just starting to read through some of it and get an
overview of how it works.

Thanks (to Isaac and everyone else who has commented) for the all the
ideas and suggestions.

Sincerely,
Laura

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

[Rich Felker]

On Wed, Mar 27, 2013 at 11:28:41PM -0500, Rob Landley wrote:
> >> it is possible to use the path/to/libc.so <command> trick or an ELF
> >> editor to circumvent this. Currently, you might want to include most
> >> of the libraries if you go for this.
> >
> >Yes, you could definitely do this with a shell script wrapper too. It
> >would work a lot better if we added command line options to the
> >dynamic linker, so that you could do something like:
> >
> >exec /opt/myapp/bin/ld-musl-$(ARCH).so.1 --libpath /opt/myapp/lib -- \
> >  /opt/myapp/bin/myapp "$@"
> 
> You're aware that other C libraries let you switch this off because
> it renders the noexec flag to mount completely useless, right? Or
> did you have a fix for that?

You can do the same thing via LD_PRELOAD, and probably a number of
other ways. In my opinion, trying to prevent a user who already has a
unix account and non-restricted shell from running their own binaries
is usually a misguided security effort. If somebody is using musl in a
situation where they can really benefit from this, or if it just makes
their boss who knows nothing about security happy, it would be super
easy to patch out these features. If at some future date we have
switchable build features (but see the past threads on this topic for
some thoughts on the scope of such), and there's demand, locking down
the dynamic linker/loader could perhaps be one of them.

Rich