musl

server OS

Message-ID: <CADm8ZdUcR3qGjHBNnWP6uXONmCDbfzw7fQDTog5QHUsdxsSZUQ@mail.gmail.com>
Date: Mon, 14 Aug 2017 12:59:41 -0500
From: wdlkmpx <wdlkmpx@...il.com>
To: Denys Vlasenko <vda.linux@...glemail.com>
Cc: busybox <busybox@...ybox.net>, musl <musl@...ts.openwall.com>
Subject: Re: bbox: musl versus uclibc

I'm sure there was plenty of people willing to contribute  to uclibc,
there is even an updated fork.

The project has been badly managed.. thats the only reason i can think
of for this situation  to happen

On 8/14/17, Denys Vlasenko <vda.linux@...glemail.com> 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.
>
> 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.
>
> (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).
>
> 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.
> 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.
>
> 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
>
> Whee!
> _______________________________________________
> busybox mailing list
> busybox@...ybox.net
> http://lists.busybox.net/mailman/listinfo/busybox
>