[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1364444921.18069.1@driftwood>
Date: Wed, 27 Mar 2013 23:28:41 -0500
From: Rob Landley <rob@...dley.net>
To: musl@...ts.openwall.com
Cc: musl@...ts.openwall.com
Subject: Re: Will musl work as a lsb alternative? (was Re: re:
musl setup attempt)
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@...ifal.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
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.
