public inbox for libc-help@sourceware.org
 help / color / mirror / Atom feed
From: Letu Ren <fantasquex@gmail.com>
To: Adhemerval Zanella <adhemerval.zanella@linaro.org>
Cc: libc-help@sourceware.org
Subject: Re: How to skip test when building glibc
Date: Wed, 15 Jun 2022 19:48:16 +0800	[thread overview]
Message-ID: <CAEUwDuBcR9ZrVhL3DanWTMMFchrL0nSezOneoDteP+OMKU1wtg@mail.gmail.com> (raw)
In-Reply-To: <2323859E-CD57-4DB0-88EC-74901E407D35@linaro.org>

Hi,

> It depends of what you are doing on your build script. The ‘make’ rule does
> not run unit unit test, so if you intend to just build glibc it should be suffice.

I'm currently trying to build glibc for ArchLinux RISC-V. My build
script executes `make` then `make check`. "It is highly recommended to
have check() as it helps to make sure software has been built
correctly and works fine with its dependencies." according to
ArchLinux wiki Creating packages. So I think I need to `make check`.

> However, if you are trying to run the expected make and make check you
> try to not run the tests itself with the extra ‘run-built-tests=no’ rule with
> ‘make check’.

As I'm new to libc, I'm not sure what `run-built-tests=no` does
exactly. I cannot find a wiki page which mentions this make variable.
I found some mail archives about it. "If you look at some of the
Makefiles in glibc, it conditionally includes/excludes some tests from
being built based on the value of run-built-tests.". And according to
glibc/Makeconfig, "Whether to run test programs built for the
library's host system." I wonder what this variable does exactly and
whether `make check run-built-tests=no` can make sure glibc built by
myself is able to work correctly.

> Unfortunately, there is no way to avoid specific tests in a default 'make check’
> and this is intentional: a failure really should represent an issue that might be
> investigated.
>
> We are trying to either get rid of flaky tests or improve them in a way to make
> them report robust output, to avoid environment issues that might mislead
> the runner.
>
> What kind of issue are you seeing in you environment?

I encountered 16 test failures. 11 of them are due to timeouts.
FAIL: nss/tst-nss-files-hosts-getent
FAIL: nss/tst-nss-files-hosts-multi
FAIL: string/test-memcpy
FAIL: string/test-memcpy-large
FAIL: string/test-mempcpy
FAIL: stdio-common/tst-vfprintf-width-prec
FAIL: stdio-common/tst-vfprintf-width-prec-mem
FAIL: resolv/tst-resolv-res_init-multi
FAIL: malloc/tst-malloc-too-large-malloc-hugetlb2
FAIL: nptl/tst-mutex10
FAIL: locale/tst-localedef-path-norm

 And Five of them are mentioned in release notes of glibc v2.35. So I
think those failures are expected.
FAIL: math/test-float-j0
FAIL: math/test-float32-j0
FAIL: stdlib/tst-strfrom
FAIL: stdlib/tst-strfrom-locale
FAIL: stdlib/test-bz22786

As far as I know, ArchLinux officially skips some tests using  sed in
Makefile. Just simply remove some tests. In my case, I cannot simply
sed, because I cannot find test-float-j0, which is generated in
runtime. I planned to execute `TIMEOUTFACTOR=300 make check` to make
sure no timeout issue occurs. So the only problem is how to deal with
five expected to fail tests. Could you please give me some advice?

  reply	other threads:[~2022-06-15 11:48 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-06-11  6:49 Letu Ren
2022-06-14 23:15 ` Adhemerval Zanella
2022-06-15 11:48   ` Letu Ren [this message]
2022-06-15 12:11     ` Florian Weimer
2022-06-15 12:51       ` Letu Ren
2022-06-15 20:33         ` Adhemerval Zanella
2022-06-16  5:13           ` Letu Ren
2022-06-16 17:43             ` Adhemerval Zanella
2022-06-17  8:12               ` Letu Ren
2022-06-21 12:21                 ` Adhemerval Zanella
2022-08-17  8:19                   ` Letu Ren

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAEUwDuBcR9ZrVhL3DanWTMMFchrL0nSezOneoDteP+OMKU1wtg@mail.gmail.com \
    --to=fantasquex@gmail.com \
    --cc=adhemerval.zanella@linaro.org \
    --cc=libc-help@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).