On Sun, Aug 16, 2020 at 1:48 AM Hauke Mehrtens <[email protected]> wrote: > > On 8/15/20 11:02 AM, Felix Fietkau wrote: > > On 2020-08-14 23:30, Rosen Penev wrote: > >> uClibc-ng works fine. Additionally, most packages have been fixed to > >> compile with uClibc-ng. > >> > >> Signed-off-by: Rosen Penev <[email protected]> > > It does not make sense to maintain uClibc-ng for anything other than arc > > (the only arch that needs it). In fact, once arc is switched to glibc, > > we should remove uClibc-ng entirely. > > Synopsys ARC HS cores (ARCv2 ISA) support was added to glibc 2.32: > https://sourceware.org/pipermail/libc-announce/2020/000029.html > > As far as I understand this should make it possible for us to use glibc > 2.32 for ARC instead of uClibc-ng. I do not have any hardware with these > ARC cores and I do not know of any emulation environment like qemu > supporting ARC, so testing this would not be possible for me. It also > looks like Synopsys is not so much interested in upstream OpenWrt > support for their CPUs any more. > > We are currently using glibc 2.31, updating glibc will probably break > some packages as always with glibc updates. If someone wants to update > glibc to 2.32 and make ARC use it by default I would support this. Sure. But this is beside the point. uClibc-ng is not broken in any way.
I use it for testing under malta. > > Hauke > _______________________________________________ openwrt-devel mailing list [email protected] https://lists.openwrt.org/mailman/listinfo/openwrt-devel
