Segmentation fault in __uClibc_main on m68k

[Rob Landley]

On 06/08/2015 10:35 AM, Thomas Petazzoni wrote:
> Waldemar, Rob,
> 
> On Sat, 30 May 2015 10:06:08 +0200, Waldemar Brodkorb wrote:
> 
>>> Remember when buildroot announced they would switch their default libc
>>> if the uClibc developers couldn't get a new release out? Remember how
>>> that was over a year ago, ala
>>> http://lists.busybox.net/pipermail/uclibc/2014-February/048252.html ?
>>> Well instead what happened was
>>> http://lists.busybox.net/pipermail/buildroot/2013-October/079661.html
>>> became http://git.buildroot.net/buildroot/commit/?id=c29799330464fb5d152f1b3d550fcbda69c58a3d
>>> which became https://www.phoronix.com/scan.php?page=news_item&px=Musl-Libc-GCC-Support
>>> and at this point it's pretty much over except the cleanup. They
>>> didn't _announce_ a migration, they just did it. At this point if
>>> uClibc had a new release I expect they'd smile and nod and _continue_
>>> not to care because there are better alternatives now, once that
>>> haven't established a pattern of chronic multi-year development
>>> constipation.
>>
>> That is not correct. They did not silently migrate to musl.
>> Musl is a choice like Gnu Libc in their buildsystem.
>>
>> They will migrate in the next release cycle, but they migrate to
>> uClibc-ng as default C library for their system.
> 
> Correct. Contrary to what Rob said, we (Buildroot) have only added
> support for Musl, not switched to it as our default C library.

Indeed. I wasn't trying to speak for the project, just saying that all
the buildroot users I know moved over already. (Not all to musl, some
went to glibc.)

> We
> actually discussed switching to glibc as the default C library, but
> never to musl. We want to offer the option of using musl, but for the
> moment not as the default. Also our musl support is still experimental,
> and there are lots of packages in Buildroot that do not yet build with
> musl.
> 
> However, we are indeed quite desperate about the state of uClibc and
> the lack of stable releases. Which is why I've personally encouraged
> Waldemar to do the uClibc-ng project, Buildroot offers the option of
> using uClibc-ng, and I will propose to make that the default C library
> choice in the next Buildroot release.

I see another uClibc fork as increasing fragmentation. Manuel Nova had a
fork. S.J. Hill had a fork. Peter Mazinger had a fork. Mike Frysinger
had a fork. The Code Sourcery guys had a fork. "Let's try to fix uclibc
by forking it" was the approach people tried back in 2007. It didn't
work then, I don't see why it would work better now.

There are still _three_ threading implementations, incoherent locale
support, a tangled mess of headers copied from random glibc snapshots,
the kconfig in current git _still_ has "Manuel's Hidden Warnings", the
root of the Kconfig tree is "extra/Configs" which you just have to
_know_ (what does "extra" mean in this context, "cannot compile this
without?"), there's still the HAS_MMU/USE_MMU nonsense (both showing up
in "target architecture features and options" when it's just one choice:
you've either enabled mmu support or you haven't)...

People have been working at cross-purposes in uclibc for many years,
abandoning half-finished projects that never got removed, and cleanup
was never a priority because glibc was inherently so much worse that
just not being a gnu project made it smell like roses in comparison. I
complained about this crap over the course of many years. I didn't stop
complaining because it got fixed, but because an alternative appeared
that was neither a giant mass of scar tissue nor moribund.

That said, I can see the appeal of uclibc-ng for buildroot: you've
effectively already _been _maintaining your own uClibc fork for years,
and migrating a major system component is painful and disruptive. Heck,
a huge amount of your build plumbing is running sed against uclibc
config symbols, just cleaning that _out_ for something like musl would
be quite the chore.

But the potential userbase of uclibc-ng is a subset of the historical
userbase of uclibc. (Explaining to a newbie why after they select NPTL
they can still select PTHREADS_DEBUG_SUPPORT in the giant forest of
overcomplicated Kconfig plumbing is not a task for the weak of stomach.)
It's maintenance of legacy code, bionic or musl make way more sense for
new deployments.

> At this point, I don't think there's any hope for uClibc to ever do a
> release.

Even if they did, one release would not solve a chronic problem going
back almost a full decade.

Rob