This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH v8 2/2] Y2038: make __tz_convert compatible with 64-bit-time
On Sat, 29 Sep 2018, Albert ARIBAUD wrote:
> > [...]
> > Summary of test results:
> > 132 FAIL
> > 5788 PASS
> > 11 UNSUPPORTED
> > 17 XFAIL
> > 2 XPASS
> > Makefile:345: recipe for target 'tests' failed
> > make[1]: *** [tests] Error 1
> > make[1] : on quitte le répertoire « /home/3adev/glibc/src »
> > Makefile:9: recipe for target 'check' failed
> > make: *** [check] Error 2
>
> Is it normal that the make check fail with a non-zero number of FAIL and
> XFAIL?
You should expect XFAILs (for example, for conform/ tests that
deliberately test features of the relevant standard that are either not
provided by glibc, or are deliberately unsupported).
You should not expect anything like 132 FAILs; you'll need to get a
working configuration for testing without so many FAILs on unmodified
sources before you can effectively test proposed patches.
> Is it is a normal result (i.e. this release of glibc is known to FAIL
> and XFAIL this way for x86_64), then where can I find the expected FAIL
> and XFAIL details for a given architecture and a given release of glibc?
See the per-release wiki pages, e.g.
<https://sourceware.org/glibc/wiki/Release/2.28>. That shows 17 XFAILs as
expected for x86_64, but no FAILs. (Ignore the results for WSL - the
Windows subsystem for Linux emulation - all they show is defects in that
subsystem, it's not a suitable environment for normal glibc testing.)
On Ubuntu 18.04 (using a locally built compiler - if you do that, note you
need to copy libgcc_s.so.* and libstdc++.so.* into the build directory
before running the tests) I get two FAILs:
FAIL: resolv/tst-resolv-ai_idn
FAIL: resolv/tst-resolv-ai_idn-latin1
Those appear in the architecture-independent section of the wiki page, for
systems with too-old libidn2.
For 32-bit testing on 64-bit Ubuntu 18.04 (again, with a locally built
compiler) I get one FAIL:
FAIL: nss/tst-nss-test3
--
Joseph S. Myers
joseph@codesourcery.com