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 _______________________________________________ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
