Re: Switching from uClibc to glibc as the default in Buildroot?

[Rich Felker <dalias@aerifal.cx>]

On Wed, Feb 19, 2014 at 12:26:43AM +0100, Thomas Petazzoni wrote:
> Dear Rich Felker,
> 
> On Tue, 18 Feb 2014 18:17:59 -0500, Rich Felker wrote:
> 
> > As maintainer of musl libc (http://www.musl-libc.org), I'd like to
> > suggest it as an alternative to switching to glibc. Obviously sticking
> > with uClibc as the default would probably be the least invasive for
> > your user base, but if that turns out not to be feasible, I think musl
> > might be a better fit for most Buildroot users. Both musl's small size
> > and strong robustness aims are attractive from an embedded
> > perspective. We are about to make a 1.0 release and have active
> > development plans following 1.0 as well.
> > 
> > musl's arch coverage is still considerably less than uClibc's or
> > glibc's, but the amount of work needed to add a port is also much
> > lower (less than 20 small mandatory port-specific files aside from
> > bits headers to match kernel/ABI-specific types) and we have an active
> > development community willing to help getting additional ports
> > integrated upstream. Right now we have i386, x86_64, arm(32),
> > mips(32), microblaze, and powerpc(32); I expect to also merge the
> > in-progress superh port before the next release.
> 
> Thanks a lot Rich for this proposal.
> 
> In fact, I am myself interested in musl: I have already added the
> possibility of using external musl toolchains with Buildroot, and I
> have started to work on integrating musl support in the internal
> toolchain backend of Buildroot. So you can clearly expect musl to be
> fully supported by Buildroot in the coming months.

Great. If you haven't already seen them, the GCC patches at
http://musl.codu.org/ may be useful.

> Since we don't yet have this support in Buildroot, I believe it is too
> early to consider making musl the default C library. But I definitely
> want to see musl supported in Buildroot, in order to help make its
> usage more widespread.

This sounds reasonable. In this light, it might be good to hold off on
switching away from uClibc for a little longer. This would give some
time to evaluate what can be done to maintain uClibc support, and if
not, you would have a chance to evaluate musl in Buildroot to
determine whether musl or glibc might be a better choice for the new
default. (BTW, if you do switch the default, do you have a plan for
how long uClibc support would be maintained as the non-default
option?)

> Do you intend to have support for non-MMU architectures in musl?

At present there isn't a plan to, but we're not particularly opposed
to it either. The big questions are how invasive it would be and
whether we can provide full functionality in any reasonable way. The
answers to those questions wouldn't translate directly to a yes or no
but would be an important part of considerations. It would probably
help to have someone familiar with the technical aspects of supporting
non-MMU archs discuss it with us on our mailing list or IRC channel.

Rich