[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1364392705.18069.0@driftwood>
Date: Wed, 27 Mar 2013 08:58:25 -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 08:40:37 PM, 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.
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
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.
