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 ku...@gentoo.org 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
