On Fri, Jul 10, 2020 at 8:55 AM Vineet Gupta via Libc-alpha <libc-al...@sourceware.org> wrote: > > 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.
That's the same with me. The toolchain wasn't rebuilt but glibc was built from a clean directory. I am rebuilding now with a rebuilt toolchain. > > Some of the failed tests have prints about static TLS block ... so I'm > wondering > if they could be related ? I see the same messages. > > | $ cat dlfcn/tststatic.out > | .../build/libc.so.6: cannot allocate memory in static TLS block That's what I see as well. > > 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. Good question! Alistair _______________________________________________ linux-snps-arc mailing list linux-snps-arc@lists.infradead.org http://lists.infradead.org/mailman/listinfo/linux-snps-arc
