[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: misc/55757 (Builds fail to clean up temporary files)
On 23-05-21 07:05, Andreas Gustafsson wrote:
| lukem%NetBSD.org@localhost asked:
| > Is this still an issue building -current?
| Thank you for looking into this. Looks like it is no longer an issue
| building -current. I just checked the /tmp on babylon5.netbsd.org,
| and although it is still accumulating temporary files, it is now doing
| so at a much slower rate than when the PR was filed, and all the ones
| I examined were either from builds of branches other than HEAD or from
| builds of historical versions of -current.
Are you happy for the PR to be closed now, or do you want to wait until
you've done root cause analysis using automated bisection as described
| > I've looked through the sources for "cdtor.c" references and it's
| > just in gcc's collect2.c. There were some changes in how that
| > file was generated in the import of gcc 9.3.0 on 2020-09-05.
| > As far as I can tell, the *cdtor.c and *cdtor.o files are
| > saved persistently with -save-temps, or are created with mkstemps()
| > by make_temp_file_with_prefix() (backend for make_temp_file())
| > in libiberty/make-temp-file.c.
| > Files created by mkstemps() should be cleaned up on process exit,
| > unless the (gcc) process terminates abnormally.
| I don't think it was fixed by the gcc 9.3.0 import specifically,
| because the PR said the problem was present in an amd64 build of
| sources from 2020-10-26, which is after gcc 9.3.0 was enabled on
| amd64. I'm currently running an automated bisection to find out when
| it was actually fixed, but that will take another day or so to
| > If the files are still occurring, are they from the tools gcc,
| > or the hosts's native gcc?
| According to the PR, the .ld files are from the build of biosboot,
| and since biosboot is not itself a tool, presumably the files are
| from the tools gcc.
| Andreas Gustafsson, gson%gson.org@localhost
It would be interesting to know where the issue got resolved.
That said, if it was an issue in the host compiler (e.g., older gcc
with a bug in temp file handling), then it's quite feasible that
the bug is observed in a build of -current after the 9.3.0 gcc was
imported - i.e., the PR being 6 weeks after said import - depending
upon the age of the host compiler.
Main Index |
Thread Index |