[tlbuild] Broken TL build

[Michael Orlitzky]

On Mon, 2022-01-17 at 07:18 +0100, Mojca Miklavec wrote:
> 
> What has caught my attention after reading Norbert's email is that
> i386 and x86_64 linux weren't broken for me. But on a closer
> investigation it looks like the error is random.
> i386-linux always worked, x86_64-linux worked in 1 out of 3 attempts,
> x86_64-linuxmusl worked in 2 out of 3 attempts, amd64-openbsd6.9
> worked in 1 out of 3 attempts (while no other OpenBSD build ever
> succeeded: neither the same OS version nor the same architecture)
> 

Yesterday I was able to reproduce *a* race condition,

  libtool: link: gcc -Wimplicit -Wreturn-type -O0 -pipe -fuse-ld=mold
  -Wl,-O1 -Wl,--as-needed -o makecpool makecpool.o 
  rm -f libweb2c.a
  ar cru libweb2c.a kps.o 
  echo timestamp >stamp-makecpool
  ranlib libweb2c.a
  rm -f libweb2c.a
  ar cru libweb2c.a kps.o 
  ranlib: 'libweb2c.a': No such file

but that's not the one in your build logs. Today I put `make clean &&
make -j6` on a loop and was able to reproduce the one you saw as well,

  libtool: link: gcc -Wimplicit -Wreturn-type -O0 -pipe -fuse-ld=mold 
  -Wl,-O1 -Wl,--as-needed -o makecpool makecpool.o 
  echo timestamp >stamp-makecpool
  mv: cannot stat '.deps/kps.Tpo'rm -f libweb2c.a

I can only be stochastically sure, but adding

  web2c_DEPENDENCIES =
  fixwrites_DEPENDENCIES =
  splitup_DEPENDENCIES =

to Makefile.am seems to solve the problem. I find this plausible,
because it would explain why

  web2c_LDADD = -L. -lweb2c

was used instead of the usual

  web2c_LDADD = libweb2c.a

in the first place. The former keeps *_DEPENDENCIES empty.