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.