| Message ID | 20200814213004.230506-3-rosenp@gmail.com |
|---|---|
| State | Rejected |
| Headers | show |
| Series | [1/3] uClibc-ng: update package from 1.0.31 to 1.0.34 | expand |
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 <rosenp@gmail.com> 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. - Felix
On Sat, Aug 15, 2020 at 2:02 AM Felix Fietkau <nbd@nbd.name> 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 <rosenp@gmail.com> > 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. My opinion is that it's fairly useful for testing purposes. More to the patch, there's nothing broken about uClibc-ng. > > - Felix
On 2020-08-16 00:27, Rosen Penev wrote: > On Sat, Aug 15, 2020 at 2:02 AM Felix Fietkau <nbd@nbd.name> 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 <rosenp@gmail.com> >> 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. > My opinion is that it's fairly useful for testing purposes. > > More to the patch, there's nothing broken about uClibc-ng. "testing purposes" is exactly why the dependency says "depends on BROKEN || arc" instead of "depends on !arc" This makes it clear that it's an unsupported configuration, but it still allows you to enable it with a few more steps. I guess a way to make it even more clear would be to introduce an 'UNSUPPORTED' config symbol to distinguish it from 'BROKEN', but I'm not sure if it's worth adding. - Felix
On Sat, Aug 15, 2020 at 9:49 PM Felix Fietkau <nbd@nbd.name> wrote: > > On 2020-08-16 00:27, Rosen Penev wrote: > > On Sat, Aug 15, 2020 at 2:02 AM Felix Fietkau <nbd@nbd.name> 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 <rosenp@gmail.com> > >> 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. > > My opinion is that it's fairly useful for testing purposes. > > > > More to the patch, there's nothing broken about uClibc-ng. > "testing purposes" is exactly why the dependency says > "depends on BROKEN || arc" instead of "depends on !arc" BROKEN implies that something is broken about it, which is not true. The main motivation behind this patch is that enabling "Enable broken packages" in Advanced Options ends up enabling actual broken packages in my .config which is not what I want. > > This makes it clear that it's an unsupported configuration, but it still > allows you to enable it with a few more steps. > > I guess a way to make it even more clear would be to introduce an > 'UNSUPPORTED' config symbol to distinguish it from 'BROKEN', but I'm not > sure if it's worth adding. Probably not. For someone to enable uClibc-ng, they would need to enable Advanced Options. Most of the options there are for testing purposes anyway... > > - Felix
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 <rosenp@gmail.com> > 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. Hauke
On Sun, Aug 16, 2020 at 1:48 AM Hauke Mehrtens <hauke@hauke-m.de> 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 <rosenp@gmail.com> > > 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 >
diff --git a/toolchain/Config.in b/toolchain/Config.in index cb557d4ad3..b1f7b1e5d6 100644 --- a/toolchain/Config.in +++ b/toolchain/Config.in @@ -250,7 +250,6 @@ choice config LIBC_USE_UCLIBC select USE_UCLIBC bool "Use uClibc" - depends on BROKEN || arc config LIBC_USE_MUSL select USE_MUSL
uClibc-ng works fine. Additionally, most packages have been fixed to compile with uClibc-ng. Signed-off-by: Rosen Penev <rosenp@gmail.com> --- toolchain/Config.in | 1 - 1 file changed, 1 deletion(-)