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

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

[Anthony G. Basile]

Hi everyone,

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]
E-Mail    : blueness@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

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

[Thomas Mueller]

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

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.

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

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.

Tom

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

[Jaco Kroon]

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

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

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

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

[Anthony G. Basile]

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
> 

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : blueness@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

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

[Thomas Mueller]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 3390 bytes --]

from "Anthony G. Basile" <blueness@gentoo.org> date: Tue, 5 Jan 2021 16:05:44 -0500
> 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.

I can't imagine crossdev could be nastier than Cross Linux From Scratch (CLFS).

CLFS seems to have low activity, is updated only sporadically, and some of the commands have syntax errors and have to be modified to fit a different implementation of bash.

Even installing Linux kernel headers does not work, fails with error messages, strange to anybody familiar with FreeBSD and NetBSD.

Idea that Linux kernel headers need to be sanitized makes me wonder if this is an idiosyncrasy peculiar to Linux.

"make headers_install" is not a trivial matter.

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

Maybe explain on website what it takes to prepare a pre-build stage3 (or stage1 or 2?)?

There are also several cross-toolchain systems such as Pengutronix (www.ptxdist.org), OpenADK (www.openadk.org), crosstool-ng (crosstool-ng.org) that can be configured for glibc, uclibc-ng, musl, bare metal or other arches.

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

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

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

[Thomas Mueller]

> 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

I wonder if uclibc-ng people fixed the bugs since your ill fortune, or if uclibc-ng development has fallen off.

Since musl works so much better for you, you will probably not want to go back.

How did you build your March 2019 stage3, or where would I go on Gentoo website?

I would naturally seek something more current, glibc or musl probably preferable to uclibc-ng.
 
Tom

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

[Joshua Kinard]

On 1/6/2021 01:08, Thomas Mueller wrote:
>> 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
> 
> I wonder if uclibc-ng people fixed the bugs since your ill fortune, or if uclibc-ng development has fallen off.
> 
> Since musl works so much better for you, you will probably not want to go back.
> 
> How did you build your March 2019 stage3, or where would I go on Gentoo website?
> 
> I would naturally seek something more current, glibc or musl probably preferable to uclibc-ng.
>  
> Tom

I tried a more recent uclibc-ng earlier in 2020 and it still broke as soon
as it compiled ncurses.  I'm sure there's probably a compile path where if
the right libraries are rebuilt in the right order, I can get it working
again, but it's not worth the time spent.  The machine I am working on is
not a hyper-fast x86/x64 system, but rather a ~15-year old MIPS-based SGI
Octane.  gcc-10.2.0 takes ~15hrs to compile, among other things.

If I cared enough, I could probably try starting a new root image from
scratch by piecing packages together from crossdev, or find another base to
morph into a Gentoo image.  Maybe one day.

The stage3 I refer to isn't available publicly.  It was a test build I did
and never released.  Current mips stages are available on the mirrors in the
'experimental' folder.  They're primarily targeted at older big-endian
MIPS-III and MIPS-IV platforms.  As for how I built it, that's done through
our 'catalyst' tool for stage-building.  You can check the Wiki for more
info on how that works.

-- 
Joshua Kinard
Gentoo/MIPS
kumba@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