On Thu, Feb 20, 2020 at 10:37 AM Lukasz Majewski <lukma@xxxxxxx> wrote: > [2] - https://github.com/lmajewski/y2038_glibc/commits/y2038_edge I tried packaging this into a .deb package for use with rebootstrap, but ran into a couple of test failures from glibc itself, when testing the i386 version while running on an older x86_64 kernel (4.15): +---------------------------------------------------------------------+ | Encountered regressions that don't match expected failures. | +---------------------------------------------------------------------+ FAIL: elf/check-localplt FAIL: nptl/tst-cancel19 FAIL: rt/tst-mqueue2 make: *** [debian/rules.d/build.mk:116: /home/arnd/glibc-2.31/stamp-dir/check_i386] Error 1 elf/check-localplt complains about the newly added symbols Extra PLT reference: libc.so: __lutimes64 Extra PLT reference: libc.so: __wait4_time64 Extra PLT reference: libc.so: __setitimer64 Extra PLT reference: libc.so: __utime64 Extra PLT reference: libc.so: __timerfd_gettime64 Extra PLT reference: libc.so: __clock_settime64 Extra PLT reference: libc.so: __utimes64 Extra PLT reference: libc.so: __gettimeofday64 Extra PLT reference: libc.so: __clock_gettime64 Extra PLT reference: libc.so: __futimesat64 Extra PLT reference: libc.so: __clock_getres64 Extra PLT reference: libc.so: __futimes64 Extra PLT reference: libc.so: __futimens64 Extra PLT reference: libc.so: __utimensat64 Extra PLT reference: libc.so: __getrusage64 Extra PLT reference: libc.so: __timespec_get64 Extra PLT reference: libc.so: __getitimer64 Extra PLT reference: libc.so: __ppoll64 Extra PLT reference: libc.so: __timerfd_settime64 Extra PLT reference: libc.so: __clock_nanosleep_time64 Extra PLT reference: libc.so: __sched_rr_get_interval64 Extra PLT reference: libc.so: __settimeofday64 Extra PLT reference: librt.so: __timer_gettime64 Extra PLT reference: librt.so: __mq_timedreceive_time64 Extra PLT reference: librt.so: __mq_timedsend_time64 Extra PLT reference: librt.so: __timer_settime64 which seems a bug in the test suite. The other two get a segfault that I have not debugged, but I guess this is likely a problem in your patches. Have you seen the same thing? Arnd _______________________________________________ linux-snps-arc mailing list linux-snps-arc@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/linux-snps-arc
