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

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

[Rich Felker]

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

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

[Thomas Petazzoni]

Dear Rich Felker,

On Tue, 18 Feb 2014 21:46:34 -0500, Rich Felker wrote:

> > 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.

I have definitely seen them, and used them already in the preliminary
prototypes. I have even posted a bug report some time ago:

  https://bitbucket.org/GregorR/musl-gcc-patches/issue/4/musl-gcc-patches-break-the-build-on

> 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.

This discussion about changing the default C library is definitely not
something for which we expect to make a change in the immediate future.
We're just looking at options, and trying to see what can be done to
revive the uClibc project, which remains important at least to support
non-MMU architectures.

> (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?)

We haven't discussed this, but I believe we would in any case keep
uClibc support around, even if it's no longer the default. Simply
because there are several non-MMU architectures that we want to
support, and only uClibc supports such architectures.

> > 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.

Ok.

Thanks!

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com