On 8/17/21 2:08 PM, Joshua Kinard wrote: > On 8/17/2021 13:49, Sam James wrote: >> >> >>> On 17 Aug 2021, at 16:19, Joshua Kinard <ku...@gentoo.org> wrote: >>> [snip] >>> >>> According to the uClibc-ng website, 1.0.38 was released earlier this year >>> (March 27th). Was an announcement put out somewhere about the project not >>> being maintained any further beyond that release, or has it gone quiet after >>> that? >> >> Upstream supporting something doesn't mean that's the case in Gentoo. The >> last "proper" mention of deprecating uclibc in Gentoo was from blueness >> in January this year [0]. >> >> Funnily enough: while digging for the email, I did notice you replied [1] >> and couldn't >> build ncurses, which is pretty apt for illustrating the problems here. That >> is, no developers >> within Gentoo are supporting uclibc, none of us are really surprised when >> common/core packages >> break, and the tracker [2] at least is rotting (as are other uclibc-related >> bugs). >> >> The gist is, it's not really supported anymore now. This is just about >> formally dropping >> it. I'd be really surprised if anyone is able to use this day-to-day without >> a fair amount >> of patches. >> >> In terms of "alt libcs", musl has won that fight. Maybe if somebody wants to >> step in future, >> we can look at uclibc-ng again, but I don't think we've got the resources >> right now. >> >> [0] >> https://archives.gentoo.org/gentoo-dev/message/8b376050c51c7fa9a8a05246feb8c781 >> [1] >> https://archives.gentoo.org/gentoo-dev/message/258c08a43961269338e4c9238783f8fe >> [2] https://bugs.gentoo.org/570544 >> >>> >>> I haven't been able to base a MIPS environment on uclibc-ng since 2019 when >>> Python3 in my stage3's mysteriously all started failing for unexplained >>> reasons. Thought about trying to bootstrap a new environment from scratch >>> at some point, but just haven't gotten around to it. >>> >> >> That sounds like a good reason to dump it too ;) > > The thing is, the breakage I describe is *really* weird. Unpack my 2019 > uclibc-ng stage3 on a MIPS system, chroot in, everything works fine. But > the instant you recompile ncurses inside of it, using the *same* Portage > snapshot that it was built from, the Python interpreter falls over with a > NULL deref in its curses module. I've debugged it down to the exact line of > C code in Python, but cannot find an explanation why it fails. > > I've had my share of weird crap running these SGI systems, but this one > takes the cake. That's why I gave up on uclibc-ng for a time until I could > try kickstarting a new build from scratch using OpenADK (which still > supports older pre-mips32/64r* platforms). No other choice, really, because > once Python goes down, so too does emerge. > > Even bugged it on Python's bug tracker, but no surprise it's gone ignored: > https://bugs.python.org/issue39819 > > In any event, yeah, I don't have a real issue with dropping it. I've > noticed that some of the more recent commits to it are really just ingesting > chunks of glibc and stripping out some of the macro fluff. There's actually > a change in upstream glibc I've yet to test on one of my non-coherent cache > platforms that uclibc-ng pulled in that probably breaks them in fun fun ways > (not that that platform ever worked well from the beginning, though...). >
Its broken on every arch. Its time for it to go. What little time I have I need to put into musl. -- Anthony G. Basile, Ph.D. Gentoo Linux Developer [Hardened] E-Mail : bluen...@gentoo.org GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA GnuPG ID : F52D4BBA
