Bruno Haible
2018-05-16 08:50:19 UTC
Hi Rich,
analysis [1] hold.
to be fixed soon.
their tests.
Bruno
[1] https://lists.gnu.org/archive/html/bug-gnulib/2018-03/msg00057.html
$ (cd gllib; ls -1 $(${GNULIB_CHECKOUT}/posix-modules | sed -e 's|-posix$||' | sort -u | grep -v 'nonblocking' | sed -e 's|$|.o|') 2>/dev/null )
fclose.o
fcntl.o
fflush.o
fseek.o
fseeko.o
ioctl.o
math.o
mbrlen.o
mbrtowc.o
nanosleep.o
strerror_r.o
sys_socket.o
unistd.o
wctype-h.o
http://oirase.annexia.org/tmp/build.log
We're using glibc 2.27.9000-7.fc28.riscv64 from Fedora, and the latest
gnulib from git.
It looks like the glob.o bug has been fixed
Yes. And for the rest of the .o files, the explanations from my previousfclose.o
fcntl.o
fflush.o
fseek.o
fseeko.o
ioctl.o
math.o
mbrlen.o
mbrtowc.o
nanosleep.o
strerror_r.o
sys_socket.o
unistd.o
wctype-h.o
http://oirase.annexia.org/tmp/build.log
We're using glibc 2.27.9000-7.fc28.riscv64 from Fedora, and the latest
gnulib from git.
It looks like the glob.o bug has been fixed
analysis [1] hold.
but there is still a lot of investigation to be done.
No, the other issues are known Linux or glibc problems that are not likelyto be fixed soon.
BTW the real hardware has working floating point.
Yes, otherwise some floating-point modules would be appearing here or failingtheir tests.
Bruno
[1] https://lists.gnu.org/archive/html/bug-gnulib/2018-03/msg00057.html