Re: [gentoo-dev] RFC: dropping support for uclibc-ng

[Joshua Kinard]

On 1/5/2021 16:05, Anthony G. Basile wrote:
> On 1/5/21 8:43 AM, Jaco Kroon wrote:
>> Hi Thomas,
>>
>> On 2021/01/05 13:08, Thomas Mueller wrote:
>>>> I'd like feedback from people about the possibility of dropping support
>>>> for uclibc-ng.  If you are unfamiliar, its the successor to uclibc as a
>>>> C Standard Library for embedded systems, ie a replacement for glibc
>>>> bloat.  However, it is inferior to musl which serves the same purpose
>>>> and which has now well supported in Gentoo.
>>>> I know people want musl support, but does anyone even care about
>>>> uclibc-ng?  If not, I can work towards deprecating it and putting what
>>>> little time I have towards musl.
>>>> Anthony G. Basile, Ph.D.
>>>> Gentoo Linux Developer [Hardened]
>>> Are you the only Gentoo developer working on musl and uclibc-ng?
>
> I'm the only one working on uclibc-ng.  There are some people helping
> with musl, especially the overlay.
>
>>>
>>> One thing I might try with a Gentoo uclibc-ng system is convert to musl or glibc using crossdev.
>>>
>>> From what I see on the internet, there is more support for musl than uclibc-ng, and more people working with musl than with uclibc-ng.
>
> It does seem that musl is winning the embedded libc race.
>
>>>
>>> There is a musl-cross-make cross-toolchain that can be built from non-musl or even non-Linux.
>>>
>>> https://github.com/richfelker/musl-cross-make
>>
>> I've used crossdev in the past.  It was a nasty experience, but I
>> believe crossdev in Gentoo is getting better and better, and it supports
>> many more targets.
>
> Yes it is, which is why I'm preparing pre-build stage3's on several
> arches so you don't have to x-compile.  I've done the nasty part for you.
>
>>
>>> From what I have seen, musl looks more promising than uclibc-ng, and more user- and developer-friendly.
>>>
>>> Unless somebody wants to take over uclibc-ng for Gentoo, I say better for you, with your limited time, to drop uclibc-ng in favor of musl.
>
>
> Correct, if I had the time, I'd continue to support both.  But my time
> is limited, so I need to concentrate.  I'm just looking for anyone to
> scream if I'm destroying their world by dropping uclibc-ng.  If no one
> does, then I'll begin the process of removing it from the tree.
>
>>
>> Not doing embedded work at the moment, but just out of hand as of right
>> now if I had to make a choice I'd definitely look at MUSL as first
>> choice.  So +1 for that suggestion.
>>
>> Kind Regards,
>> Jaco

I was using uclibc-ng builds for MIPS to build netboot images between 2017
and 2019 to refine my build processes.  uclibc-ng still produces smaller
overall binaries and libs for the netboot than musl does (usually ~1MB
smaller, which is actually significant, especially on SGI IP22 systems).

Unfortunately for uclibc-ng, it stopped working for me in ~2019.  I have no
clue why, either.  The March 2019 uclibc-ng MIPS stage3 I built internally
works perfectly fine when you unpack it and leave it alone, but as soon as
you compile *anything* more recent with the compiler that's when the
breaking begins.

Rebuilding ncurses in this stage3 will break Python, which breaks emerge.
Never figured it out.  I can trace the failure using GDB to a point in
Python, but not much farther beyond that.  I assume the true cause is
something in uclibc-ng itself.  Upstream seems to like to borrow chunks of
glibc for things, and I wonder if that may be partly to blame.

I eventually gave up and went to musl for MIPS/o32.  musl quite literally
JustWorks().  It's great.  Even with that tiny bit of bloat in the netboot
build (workable, cause I needed to make NFS Root an option anyways).

So long story short, I won't shed any tears if uclibc-ng goes away.

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