Re: [gentoo-dev] News Item for uClibc-ng deprecation

[Anthony G. Basile]

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 <kumba@g.o> 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    : blueness@g.o
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA