Hi Seth, Mathieu Lirzin <m...@gnu.org> writes:
> 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. Any news? Would be great if you could provide a way to reproduce this issue. Thanks. -- Mathieu Lirzin GPG: F2A3 8D7E EB2B 6640 5761 070D 0ADE E100 9460 4D37
