[Buildroot] Switching from uClibc to glibc as the default in Buildroot?

[Buildroot] Switching from uClibc to glibc as the default in Buildroot?

[Thomas Petazzoni]

Hello,

The uClibc project has not released any new version since almost two
years, despite the fact that there are numerous known issues and
limitations in 0.9.33.2, and a good set of fixes in the 0.9.33 branch
that have never been part of any release.

This lack of stable releases is causing major issues for build systems
such as Buildroot. Not only do we have to carry a large number of
backported patches to fix uClibc bugs and add missing system calls and
functionalities needed to run modern software, but we also have issues
supporting uClibc toolchains provided by other parties (such as
processor vendors), because they are not using the same set of
backported patches. The lack of releases is causing fragmentation
between the various uClibc versions, making uClibc more and more
painful to support in Buildroot.

To give you an idea, Buildroot currently has more than 50 patches on
top of uClibc 0.9.33.2:

  http://git.buildroot.net/buildroot/tree/package/uclibc/0.9.33.2/

OpenEmbedded has to use a Git version of uClibc, with a few patches:

  https://github.com/openembedded/oe-core/blob/master/meta/recipes-core/uclibc/uclibc-git.inc

OpenWRT also has a good number of patches:

  https://dev.openwrt.org/browser/trunk/toolchain/uClibc/patches-0.9.33.2

We have already asked for stable releases in September 2013 [1], then
in November 2013 [2], and finally in December 2013 [3], and still no
release has been made.

Historically, Buildroot was created as a tool to generate small Linux
systems based on uClibc, in order to test and exercise uClibc. Since
its origin, Buildroot has had uClibc as its default C library, quite
certainly helping in propagating uClibc in embedded Linux systems.

However, due to the reasons mentioned above, supporting uClibc has
proven to be more and more complicated. Therefore, at the latest
Buildroot Developers Meeting, we discussed the idea of switching to
using glibc as the default C library in Buildroot for the
architectures that glibc supports.

But before doing that, we would like to discuss this problem again
with the uClibc community, and see if something can be done to revive
the project in terms of delivering releases. Adopting a time-based
release schedule has proven to work really well for Buildroot, and we
believe this solution should be considered by the uClibc developers.

Thanks!

Thomas, on behalf of the Buildroot core developers: Peter Korsgaard,
Yann E. Morin, Samuel Martin, Thomas De Schampheleire.

[1] http://lists.uclibc.org/pipermail/uclibc/2013-September/047942.html
[2] http://lists.uclibc.org/pipermail/uclibc/2013-November/048029.html
[3] http://lists.uclibc.org/pipermail/uclibc/2013-December/048102.html
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] Switching from uClibc to glibc as the default in Buildroot?

[Thomas Petazzoni]

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.

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.

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

Best regards,

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

[Buildroot] 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

[Buildroot] Switching from uClibc to glibc as the default in Buildroot?

[Thomas Petazzoni]

Dear Khem Raj,

On Tue, 18 Feb 2014 16:23:11 -0800, Khem Raj wrote:

> > To give you an idea, Buildroot currently has more than 50 patches on
> > top of uClibc 0.9.33.2:
> >
> >   http://git.buildroot.net/buildroot/tree/package/uclibc/0.9.33.2/
> 
> Indeed, I see what you are saying here. In order to begin the process,
> can you send a list of patches
> that buildroot is carrying for inclusion into master.

Peter will confirm, but I believe that *all* our patches are backports
from the 0.9.33 branch at http://git.uclibc.org/uClibc/log/?h=0.9.33.
So there is no special fix in Buildroot that isn't already in mainline
uClibc.

We are not complaining about patches not been integrated into uClibc,
we are complaining about the fact that no stable releases are being
made from uClibc, which creates a lot of fragmentation between
providers of uClibc based toolchains.

> Secondly, would it be just fine if the release is made
> in form of a git branch and no tarballs?

I don't think this would solve the fragmentation problem. If you want
to solve it, you need to make clear stable releases on a regular basis.

And if you make a tag in git, then doing a tarball is just one 'git
archive' invocation away.

> regardless I would request
> all to send/resend the patches that are for master so we can
> collect them on patchwork here
> 
> http://patchwork.ozlabs.org/project/uclibc/list/

As explained above, this is not needed. All the patches we have are
already in mainline uClibc. We just want a release.

> given the patches and development activity we snapshot uclibc trunk
> and that works out ok.

Right, but that doesn't solve the fragmentation problem. When someone
builds an uClibc toolchain with for example Crosstool-NG, or uses the
pre-built uClibc toolchain provided by Analog Devices for the Blackfin
architecture, those toolchains don't have a uClibc with as many
patches as we have in Buildroot, and so they lack some modern system
calls (execvpe, dup3, etc.).

By having regular releases, we would encourage uClibc downstream users
(Crosstool-NG, Analog Devices, and all other projects) to regularly
upgrade, and therefore reduce the fragmentation.

Thanks,

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

[Buildroot] Switching from uClibc to glibc as the default in Buildroot?

[Peter Korsgaard]

>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:

 > Dear Khem Raj,
 > On Tue, 18 Feb 2014 16:23:11 -0800, Khem Raj wrote:

 >> > To give you an idea, Buildroot currently has more than 50 patches on
 >> > top of uClibc 0.9.33.2:
 >> >
 >> >   http://git.buildroot.net/buildroot/tree/package/uclibc/0.9.33.2/
 >> 
 >> Indeed, I see what you are saying here. In order to begin the process,
 >> can you send a list of patches
 >> that buildroot is carrying for inclusion into master.

 > Peter will confirm, but I believe that *all* our patches are backports
 > from the 0.9.33 branch at http://git.uclibc.org/uClibc/log/?h=0.9.33.
 > So there is no special fix in Buildroot that isn't already in mainline
 > uClibc.

That's the plan atleast. We normally don't carry any feature patches
(besides backports), but I would need to check to 100% sure.

-- 
Bye, Peter Korsgaard

[Buildroot] Switching from uClibc to glibc as the default in Buildroot?

[Thomas Petazzoni]

Dear Khem Raj,

On Tue, 18 Feb 2014 18:43:41 -0800, Khem Raj wrote:

> > There are a great number of fixes since the last numbered release and I for one would greatly appreciate having at least a "testing" release with a bumped version number to use. Other than the ldso stat call problem I reported a couple of weeks ago, uClibc trunk has been working fairly well, and most bugs I run into are the typical growing pains of toolchain building from scratch rather than uClibc problems.
> 
> so get going start testing git/master and report issues or successes you have.
> help in testing it out, run uclibc test suites or any others you have setups for

Please break the chicken-and-egg problem, and release 2014.02-rc1 right
now, spit out a call for testing, and release 2014.02 at the end of the
month. (Or pick any other date you want, those are just suggestions).

It's by creating rhythm and cadence in the release schedule that you
will encourage people to test the release candidates and report bugs.
Nobody wants to test a moving git/master.

> > I don't think that a "Git release" is appropriate for these reasons. Besides, if you did tag a Git commit with a version number, there's also no reason not to put out a tarball to go with it, right?
> 
> it needs some work whereas with git you can download the tars from cgit, but not a big issue. We can release tar balls too.

As I said earlier, I believe tarballs are still useful today.

Best regards,

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

[Buildroot] Switching from uClibc to glibc as the default in Buildroot?

[Peter Korsgaard]

>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:

 > Dear Khem Raj,
 > On Tue, 18 Feb 2014 18:43:41 -0800, Khem Raj wrote:

 >> > There are a great number of fixes since the last numbered release and I for one would greatly appreciate having at least a "testing" release with a bumped version number to use. Other than the ldso stat call problem I reported a couple of weeks ago, uClibc trunk has been working fairly well, and most bugs I run into are the typical growing pains of toolchain building from scratch rather than uClibc problems.
 >> 
 >> so get going start testing git/master and report issues or successes you have.
 >> help in testing it out, run uclibc test suites or any others you have setups for

 > Please break the chicken-and-egg problem, and release 2014.02-rc1 right
 > now, spit out a call for testing, and release 2014.02 at the end of the
 > month. (Or pick any other date you want, those are just suggestions).

Inded. When Bernard suggested the same last year I did test and reported
issues, but never got any reply:

http://lists.uclibc.org/pipermail/uclibc/2013-November/048093.html

-- 
Bye, Peter Korsgaard

[Buildroot] Switching from uClibc to glibc as the default in Buildroot?

[Mike Zick]

On Wed, 19 Feb 2014 09:32:02 +0100
Peter Korsgaard <jacmet@uclibc.org> wrote:

> Inded. When Bernard suggested the same last year I did test and
> reported issues, but never got any reply:
> 
> http://lists.uclibc.org/pipermail/uclibc/2013-November/048093.html
>

A mailing-list setup problem at uClibc?

Because following that thread shows your suggested change was
applied.

So fixing up their mailing-list operation could become a separate
subject thread.

Maybe something as simple as echoing the "[commit]" messages to
their mailing list would fix this sort of communication lack.

Mike

[Buildroot] Switching from uClibc to glibc as the default in Buildroot?

[Thomas De Schampheleire]

Hi all,

On Wed, Feb 19, 2014 at 9:32 AM, Peter Korsgaard <jacmet@uclibc.org> wrote:
>>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:
>
>  > Dear Khem Raj,
>  > On Tue, 18 Feb 2014 18:43:41 -0800, Khem Raj wrote:
>
>  >> > There are a great number of fixes since the last numbered release and I for one would greatly appreciate having at least a "testing" release with a bumped version number to use. Other than the ldso stat call problem I reported a couple of weeks ago, uClibc trunk has been working fairly well, and most bugs I run into are the typical growing pains of toolchain building from scratch rather than uClibc problems.
>  >>
>  >> so get going start testing git/master and report issues or successes you have.
>  >> help in testing it out, run uclibc test suites or any others you have setups for
>
>  > Please break the chicken-and-egg problem, and release 2014.02-rc1 right
>  > now, spit out a call for testing, and release 2014.02 at the end of the
>  > month. (Or pick any other date you want, those are just suggestions).
>
> Inded. When Bernard suggested the same last year I did test and reported
> issues, but never got any reply:
>
> http://lists.uclibc.org/pipermail/uclibc/2013-November/048093.html
>

Any further evolution in this matter?

Until now, this mail thread did not seem to have triggered any real
activity from the uClibc community.

Khem Raj: what is the plan forward? You have requested patches to be
sent, and testing to be performed, and the Buildroot community has
responded by telling that we only have patches that are already in the
uClibc tree (unreleased) and we have been testing this for a long
while already, without problems.

Maybe you feel this is not enough, in which case kindly provide more
details about what you consider blocking points to make a release, or
even a release candidate.

Thanks,
Thomas De Schampheleire

[Buildroot] Switching from uClibc to glibc as the default in Buildroot?

[Bernhard Reutner-Fischer]

On Fri, Mar 07, 2014 at 09:07:27AM +0100, Thomas De Schampheleire wrote:
> Hi all,
> 
> On Wed, Feb 19, 2014 at 9:32 AM, Peter Korsgaard <jacmet@uclibc.org> wrote:
> >>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni@free-electrons.com> writes:
> >
> >  > Dear Khem Raj,
> >  > On Tue, 18 Feb 2014 18:43:41 -0800, Khem Raj wrote:
> >
> >  >> > There are a great number of fixes since the last numbered release and I for one would greatly appreciate having at least a "testing" release with a bumped version number to use. Other than the ldso stat call problem I reported a couple of weeks ago, uClibc trunk has been working fairly well, and most bugs I run into are the typical growing pains of toolchain building from scratch rather than uClibc problems.
> >  >>
> >  >> so get going start testing git/master and report issues or successes you have.
> >  >> help in testing it out, run uclibc test suites or any others you have setups for
> >
> >  > Please break the chicken-and-egg problem, and release 2014.02-rc1 right
> >  > now, spit out a call for testing, and release 2014.02 at the end of the
> >  > month. (Or pick any other date you want, those are just suggestions).
> >
> > Inded. When Bernard suggested the same last year I did test and reported
> > issues, but never got any reply:
> >
> > http://lists.uclibc.org/pipermail/uclibc/2013-November/048093.html
> >
> 
> Any further evolution in this matter?
> 
> Until now, this mail thread did not seem to have triggered any real
> activity from the uClibc community.
> 
> Khem Raj: what is the plan forward? You have requested patches to be
> sent, and testing to be performed, and the Buildroot community has
> responded by telling that we only have patches that are already in the
> uClibc tree (unreleased) and we have been testing this for a long
> while already, without problems.
> 
> Maybe you feel this is not enough, in which case kindly provide more
> details about what you consider blocking points to make a release, or
> even a release candidate.

Well, see ML archives with a mail from Peter who tested a somewhat
recent master and found ARM !LFS to be broken (i still consider !LFS to
be an important thing to support, despite the maintenance burden).
[the exact november mail above, btw]
We have touched this on master as
00571b43df2e0554d1b0716681832ba9975177c5 so this in fact did trigger a
reaction from "the uClibc community". No reaction from the buildroot
folks that current master resolved this !LFS ARM failure. Zilch.
See?
Where is your waterfall buildbot page that shows current uClibc-master
state, again?


If buildroot would rebase their patches against current 0.9.33 branch
then i would happily merge the backports that you cherry-picked and call
it 0.9.33.++x but current master is just not in a condition that i feel
comfortable to call 0.9.34. It works for big systems but as you can see
with the ARM !LFS case has some severe regressions and i don't currently
have time to tackle them all by myself.

So what you can do is, either test and fix (!) master for non-fat target
images at least, or help with re-baseing the buildroot, openwrt, freetz,
you-name-it patches to the 0.9.33 branch for us to merge.

thanks and cheers,

[Buildroot] Switching from uClibc to glibc as the default in Buildroot?

[Vineet Gupta]

On Thursday 13 March 2014 01:54 AM, Bernhard Reutner-Fischer wrote:
> On Fri, Mar 07, 2014 at 09:07:27AM +0100, Thomas De Schampheleire wrote:
>> > Hi all,
>> > 
>> > On Wed, Feb 19, 2014 at 9:32 AM, Peter Korsgaard <jacmet-2zL2ArBv0bUdnm+yROfE0A@public.gmane.org> wrote:
>>>>>>>> > >>>>>> "Thomas" == Thomas Petazzoni <thomas.petazzoni-wi1+55ScJUtKEb57/3fJTNBPR1lH4CV8@public.gmane.org> writes:
>>> > >
>>> > >  > Dear Khem Raj,
>>> > >  > On Tue, 18 Feb 2014 18:43:41 -0800, Khem Raj wrote:
>>> > >
>>> > >  >> > There are a great number of fixes since the last numbered release and I for one would greatly appreciate having at least a "testing" release with a bumped version number to use. Other than the ldso stat call problem I reported a couple of weeks ago, uClibc trunk has been working fairly well, and most bugs I run into are the typical growing pains of toolchain building from scratch rather than uClibc problems.
>>> > >  >>
>>> > >  >> so get going start testing git/master and report issues or successes you have.
>>> > >  >> help in testing it out, run uclibc test suites or any others you have setups for
>>> > >
>>> > >  > Please break the chicken-and-egg problem, and release 2014.02-rc1 right
>>> > >  > now, spit out a call for testing, and release 2014.02 at the end of the
>>> > >  > month. (Or pick any other date you want, those are just suggestions).
>>> > >
>>> > > Inded. When Bernard suggested the same last year I did test and reported
>>> > > issues, but never got any reply:
>>> > >
>>> > > http://lists.uclibc.org/pipermail/uclibc/2013-November/048093.html
>>> > >
>> > 
>> > Any further evolution in this matter?
>> > 
>> > Until now, this mail thread did not seem to have triggered any real
>> > activity from the uClibc community.
>> > 
>> > Khem Raj: what is the plan forward? You have requested patches to be
>> > sent, and testing to be performed, and the Buildroot community has
>> > responded by telling that we only have patches that are already in the
>> > uClibc tree (unreleased) and we have been testing this for a long
>> > while already, without problems.
>> > 
>> > Maybe you feel this is not enough, in which case kindly provide more
>> > details about what you consider blocking points to make a release, or
>> > even a release candidate.
> Well, see ML archives with a mail from Peter who tested a somewhat
> recent master and found ARM !LFS to be broken (i still consider !LFS to
> be an important thing to support, despite the maintenance burden).
> [the exact november mail above, btw]
> We have touched this on master as
> 00571b43df2e0554d1b0716681832ba9975177c5 so this in fact did trigger a
> reaction from "the uClibc community". No reaction from the buildroot
> folks that current master resolved this !LFS ARM failure. Zilch.
> See?


I'm not sure if ARM !LFS failure is the same but I've posted (and reminded at
least once) regarding a !LFS build failure on ARC.

http://lists.uclibc.org/pipermail/uclibc/2014-January/048174.html
http://lists.uclibc.org/pipermail/uclibc/2014-February/048215.html

-Vineet