Jörg Schilling (9 July 2020 16:18)
> What I can say to help fixing the problem is that truss(1) shows that
> gmake calls stat(2) as a block on a larger list of files at startup
> and at that time correctly finds that the file in question does not
> exist.
gmake caches stat results and makes the reasonable assumption that they
only get invalidated for files that are targets of rules it executes.
> Then it executes some rules that have the side effect to create the
> file in question (a symlink to a source file).
>
> Gmake however never again calls stat(2) on that file but incorrectly
> claims that the file does not exist, eventhough it exists at the time
> it is really needed.
That sounds reasonable; if your make files don't say that their rule
creates a file, make doesn't know it's been created (or updated).
Rechecking for whether missing files have mysteriously appeared without
apparent cause would be a horrible pessimisation for most users of make.
> Please note that the fact that there is no explicit rule for that
> file, is caused by a workaround for another gmake bug that would cause
> a specific command to be called 4x concurrently, resulting in
> overwritten results.
Then try looking for a different work-around.
Your present work-around is a bug in your make files.
By the sounds of it, you have four files that are all created by a
single rule, which isn't a scenario make is good at. So work-arounds
are tricky: but you're more likely to get help finding a better
work-around than to persuade the maintainer of gmake to introduce a
significant pessimisation.
Eddy.
