[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130327032032.GS20323@brightrain.aerifal.cx>
Date: Tue, 26 Mar 2013 23:20:32 -0400
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: Will musl work as a lsb alternative? (was Re: re:
musl setup attempt)
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@...ifal.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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
