Hi Seth, Seth Fowler <seth.fow...@me.com> writes:
> I recently ran into what appears to be a bug in automake and I thought it > would be a good idea to let you know. > > We had noticed that running “make recheck -j8” if some source files > were dirty would cause random build failures. The symptom was that the > same file was getting built more than once by different make > processes, which led to the resulting objects being corrupted. We’d > see messages like this: > > libtool: error: ‘foo.lo’ is not a valid libtool object > > I dug into this a little and the root cause of the problem seems to be > that unlike the other top-level targets generated by automake (check, > install, etc.), recheck depends on “all” instead of “all-am”. “all” > doesn’t declare very many dependencies - it just launches a new copy > of make that builds “all-am”. Because recheck also depends on other > targets (e.g. everything in check_PROGRAMS) which might depend on some > of the same things as “all-am”, in a parallel build the original make > process and the make process spawned by “all” can end up attempting to > build the same targets. > > I fixed this for our project by copying the generated recheck rule > into our Makefile.am and replacing “all” with “all-am”. After doing > this, I could no longer reproduce the problem with “make recheck -j8”. > > It seems like that change should be made in automake itself. Or maybe I just > missed something - I’m far from an automake guru. =) Seems like a bug. In order to properly fix this in Automake, we need to have a test that allow us to reproduce the issue. Ideally you would provide this test yourself by taking inspiration from: https://git.savannah.gnu.org/cgit/automake.git/tree/t/libtool2.sh?h=micro If you are not comfortable with doing that, a tarball or a link to a repository containing a minimal automake project that allow us to reproduce the bug manually is good enough. Thanks for the report. -- Mathieu Lirzin GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
