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

[Joshua Kinard]

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

-- 
Joshua Kinard
Gentoo/MIPS
kumba@g.o
rsa6144/5C63F4E3F5C6C943 2015-04-27
177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943

"The past tempts us, the present confuses us, the future frightens us.  And
our lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic