On Mon, Nov 21 2022, Eric Sunshine wrote: > [cc:+git; taking this back to the mailing list so others can weigh in] > > On Wed, Nov 9, 2022 at 1:38 AM Sarah Julia Kriesch > <sarah.kriesch@xxxxxxxxxxxx> wrote: >> > Gesendet: Sonntag, 06. November 2022 um 21:42 Uhr >> > Von: "Eric Sunshine" <sunshine@xxxxxxxxxxxxxx> >> > >> > On Sun, Nov 6, 2022 at 2:18 PM Sarah Julia Kriesch >> > <sarah.kriesch@xxxxxxxxxxxx> wrote: >> > > We have also identified this week, that chainlint.pl --stats says "0 >> > > tests". That can explain the empty output. >> > > >> > > ~/rpmbuild/BUILD/git-2.38.1/t> /usr/bin/perl chainlint.pl --stats >> > > --emit-all chainlinttmp/tests >> > > total: 0 workers, 0 scripts, 0 tests, 0 errors, 0.01s/0.01s (wall/user) >> > >> > Was `--stats` added for debugging this issue, or is that somehow part >> > of your build process? >> > >> Yes. We tried to debug that manually. Therefore, we have added the --stats. >> >> > What is the content of the "chainlinttmp/tests" file? Is it empty? >> > >> It is empty. >> >> > It is quite curious that it reports 0 scripts. It should report 1 >> > script even if chainlinttmp/file is empty. This might point a finger >> > at File::Glob::bsd_glob() returning an empty list for some reason, or >> > the problem could be a failure with Perl "ithreads". > > Do you happen to know if Perl is built with "ithreads" on your > platform, and if so, is "ithread" support working? > > The empty "chainlinttmp/tests" file also sounds suspicious. If you > haven't already done so, I would recommend following the advice in [1] > and running each command individually which Makefile would have run; > this might allow you to isolate the problematic command or shell > construct if such exists. > > [1]: https://lore.kernel.org/git/CAPig+cS184iKk6icG6ML=X+6Ng=fJyfic8izFyp1hT40cChm4g@xxxxxxxxxxxxxx/ I can also reproduce this on gcc202. It's the same issue with ending up with an empty "tests" file. avar@gcc202:/run/user/1632/git/t$ uname -a Linux gcc202 6.0.0-4-sparc64-smp #1 SMP Debian 6.0.8-1 (2022-11-11) sparc64 GNU/Linux avar@gcc202:/run/user/1632/git/t$ lsb_release -a No LSB modules are available. Distributor ID: Debian Description: Debian GNU/Linux bookworm/sid Release: n/a Codename: bookworm The change at the tip of https://lore.kernel.org/git/221122.86cz9fbyln.gmgdl@xxxxxxxxxxxxxxxxxxx/ fixes it for me, i.e. getting rid of the perl threads stuff... That box is built with "useithreads=define", so it's not that it doesn't support threading in general.
