[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170814184812.GS1627@brightrain.aerifal.cx>
Date: Mon, 14 Aug 2017 14:48:12 -0400
From: Rich Felker <dalias@...c.org>
To: Denys Vlasenko <vda.linux@...glemail.com>
Cc: busybox <busybox@...ybox.net>, Felix Fietkau <nbd@....name>,
musl <musl@...ts.openwall.com>
Subject: Re: bbox: musl versus uclibc
On Mon, Aug 14, 2017 at 07:43:39PM +0200, Denys Vlasenko wrote:
> As uclibc is increasingly aging, I am finally forced
> to switch to musl: I'm bitten by a nasty bug in
> getopt() - hush is using it in a slightly unusual way,
> which uclibc does not expect.
While I'm glad musl is working for you, this sounds fragile unless
it's actually just a bug in uclibc, in which case it'll hopefully get
fixed. If you're relying on weird internal-state of getopt there's a
chance this could break in the future on musl or on other libcs.
Can you explain the problem you encountered on uclibc?
> I built a toolchain using
> https://github.com/richfelker/musl-cross-make
> (Rich, is this the thing I should be using?)
> and it worked with no issues at all.
Yes, it's the easiest and canonical way to get a full toolchain.
> (I can probably only wish for the README
> to also mention how to make this a _static_
> toolchain... I have a box with 32-bit userspace,
> would be awesome to be able to copy this fresh
> 64-bit toolchain to it and have it working).
If you put LDFLAGS="-static --static" (second form is a hack to
workaround libtool's stripping of -static :) in COMMON_CONFIG you
should get a static build of the toolchain, but it's linked to
whatever the libc in your build environment is.
In my config.mak I use:
ifeq ($(HOST),)
COMMON_CONFIG += CC="i486-linux-musl-gcc -static --static" CXX="i486-linux-musl-g++ -static --static"
endif
COMMON_CONFIG += CFLAGS="-g0 -Os" CXXFLAGS="-g0 -Os" LDFLAGS="-s -static --static"
to build the toolchain static-linked using an existing
i486/musl-targeting toolchain. The static in $CC/$CXX is needed
because some broken configure tests in GMP try to run test binaries
built without honoring LDFLAGS, and will fail to run if you don't have
ld-musl-i386 installed.
Now that canadian-cross support works, you could probably instead
treat i486-linux-musl as a cross compiler (host!=build) instead.
If you prefer you can use x86_64 instead, too, but I like the
toolchain binaries themselves being 32-bit simply because it saves
roughly half the ram usage when running them.
> Then I built busybox. Impressions:
>
> Only a few options did not build:
> EXTRA_COMPAT and FEATURE_VI_REGEX_SEARCH
> failed because they need GNU regexp extensions.
Yes. There was a request for the corresponding version of some of
these extensions in the POSIX regex API, which bb vi could be
converted to use if we adopted them, but there is some nontrivial
runtime cost. It probably doesn't matter now since the regexec core is
fairly slow (well, good big-O but bad constant) right now, but it may
impose a more noticable relative cost once we make regexec faster.
> FEATURE_MOUNT_NFS and FEATURE_INETD_RPC do not build
> because they need rpc/rpc.h.
> Not complaining, since them being in libc was a mistake
> in the first place.
I think glibc has dropped these too now, haven't they? AFAIK they're
just keeping the symbols for ABI compat but they're not an exposed API
for linking new code; you're supposed to use tirpc.
> Now, the good news - musl has smaller data!
> 6695 bytes versus 7129 bytes for uclibc:
>
> text data bss dec hex filename
> 894902 465 6664 902031 dc38f busybox.uclibc
> 912538 563 6132 919233 e06c1 busybox.musl
Probably getpw*/getgr* static buffers or something. musl's backend for
these just uses the buffer out of getline so as not to impose cost in
apps that don't need the legacy (non-_r) functions or an arbitrary
limit on record length.
It would be interesting to know where the text size increase comes
from. Not that big in abs difference, but given that a large portion
of the text is busybox code and not libc, it's a fairly large relative
difference. Come to think about it, it might actually be regex..
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.
