remove uClibc-ng

[neheb]

After musl was introduced, it was desired to remove uClibc-ng. As ARC
has no musl support, it was kept around. However, glibc 2.32 includes
ARC support. This makes it possible to finally remove it.

Signed-off-by: Rosen Penev rosenp@gmail.com

[adschm]

This sounds like something we should block until after the upcoming release?

[lintel]

I don't recommend this merge.

1. In fact, the current performance of musl is no better than uclibc on some platform(e.g MIPS,x86-64),
2. some commercial products old binary release was depend on uclibc.
3. pls show me the corresponding test report that musl has beter performance than uclibc on ervery platform(arch).
4. other distributions，like buildroot and entware-ng，keep support uclibc well , why openwrt not?

[neheb]

@lintel

1: This is not a question of performance
2: uClibc-ng is marked as BROKEN. Only ARC uses it currently.
3: This is not a question of performance.
4: This is OpenWrt, not others. Note that uClibc-ng is marked as BROKEN. Nobody wants to maintain it.

[adschm]

I'm putting "blocked" label on this, as I don't think we should change this before the release.

If somebody else feels differently, feel free to remove it again.

Note that I'm totally in favor of the change in general, I'm just not sure whether we should do it now. (Unless uClibc-ng is broken in a way that it can only become better ...)

[neheb]

Sure. To take devil's advocate, uClibc-ng currently compiles almost everything, according to the buildbots.

glibc on the other hand fails with many packages. Mostly because of missing -lpthread.

[neheb]

@adschm would you be open to a patch removing the !arc depend for GLIBC at least?

[adschm]

@adschm would you be open to a patch removing the !arc depend for GLIBC at least?

Can't really say. I'd recommend to get a mood on this whole issue in IRC.

[hauke]

I think removing uClibc-ng is a good thing, I do not see a big problem doing it before branching. We do not have many users of the ARC CPU targets and these are the only ones which should be affected. Maintaining uClibc-ng needs some efforts and we could reduce that.

I do not see a big advantage of uClibc-ng over musl, glibc support is nice because it is the most used libc in the Linux world.

@neheb Have you contacted Synopsys to test this on their devices?
Could you also ask them to test the gdb server, that should not also work on ARC.

I would also like to have some more testing of the glibc, so having an unimportant target using it as default would be nice.

[neheb]

I have not contacted Synopsis. I don't know what they think.

[curtdept]

@abrodkin thoughts?

[abrodkin]

@curtdept it looks good to me and I may understand benefits of simplicity with removal of "extra" libc flavors. Especially if there're no other users of uClibc except ARC and uClibc is known to not be 100% compatible with glibc (and so here and there we saw breakages which needed attention).
Though as I see from other projects like at least Linux & Buildroot glibc v2.32 may need some more attention on its own due to changes like that:

• 64-bit time
• Removal of built-in Sun RPC (removed --enable-obsolete-rpc)

But I guess it needs to be accommodated at some point anyways :)

[ynezz]

Thanks! Pulled into my staging tree at https://git.openwrt.org/openwrt/staging/ynezz.git

[vineetgarc]

Please do note that at the moment, only two glibc 32-bit ports support 64-bit time_t (ARC and RV32). So as @abrodkin mentions there might be some fallout if rest of OpenWRT is not prepared for this combination. e.g. Busybox upstream needed to adjusted. Just FYI.