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

[Rich Felker]

On Wed, Mar 12, 2014 at 09:24:17PM +0100, Bernhard Reutner-Fischer wrote:
> > 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).

Could you elaborate on why? The only reason I can think of is ABI
compatibility, and uClibc explicitly documents that the ABI is not
stable between releases.

My impression is that the reason the uClibc project is almost dead is
largely a matter of the ballooning configuration combinatorics and the
inability to test them all and keep them maintained. It's really
unfortunate that the inability to fix some configurations that should
just be deprecated/removed is essentially preventing uClibc from being
maintained (at least in the sense of having real releases) at all.

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

With all due respect, when one of uClibc's biggest downstream users is
considering switching away from uClibc, I'm not sure asking them to
take on a big part of the burden of maintaining it is the best way to
build confidence in the project. On the other hand, if there are major
downstream users who really want uClibc to succeed and get back on
track, at least some of them need to get involved in reviewing
(possibly each other's) patches, testing and reporting what
configurations are broken, etc.

Rich