On 7/10/20 2:28 AM, Florian Weimer via Libc-alpha wrote: > * Alistair Francis via Libc-alpha: > >> On Thu, Jul 9, 2020 at 2:36 PM Vineet Gupta via Libc-alpha >> <libc-al...@sourceware.org> wrote: >>> >>> On 7/9/20 2:13 PM, Vineet Gupta via Libc-alpha wrote: >>>>> Rebased ARC port on master and fired a build-many-glibcs <glibcs> now >>>>> (expect some >>>>> abilist updates). Will do a full testsuite run >>>> >>>> No regressions in sysvipc tests ! >>> >>> But quite a few regressions. Baseline is ARC port off of upstream >>> 81b1c8cbb5b4 >>> "(hurd: Simplify usleep timeout computation)" and failures below seen in >>> ARC port >>> off of today's master ffd178c651b8 "(sysv: linux: Add 64-bit time_t variant >>> for >>> shmctl)" >>> >>> FAIL: dlfcn/tststatic >>> FAIL: dlfcn/tststatic2 >>> FAIL: dlfcn/tststatic3 >>> FAIL: dlfcn/tststatic4 >>> FAIL: dlfcn/tststatic5 >>> FAIL: elf/tst-libc_dlvsym >>> FAIL: elf/tst-libc_dlvsym-static >>> FAIL: elf/tst-single_threaded-static-dlopen >>> FAIL: elf/tst-tls9-static >> >> I see the same recent-ish regressions for RV32. > > Did you rebuild from scratch? After the libc.so/ld.so ABI changes that > went in recently, it could be the result of incomplete make > dependencies.
>From scratch meaning glibc alone or the whole toolchain. I used buildroot and glibc-dirclean to nuke entire glibc but gcc was not rebuilt. I can try that too. Some of the failed tests have prints about static TLS block ... so I'm wondering if they could be related ? | $ cat dlfcn/tststatic.out | .../build/libc.so.6: cannot allocate memory in static TLS block Also while we figure this out, does this prevent ARC port from being committed. It is a functioning system otherwise: I'm doing doing cross run of testsuite with sshd etc involved and these addition 10+ failures don't seem to be getting in the way. _______________________________________________ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
