[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#26471: Automake 1.15 generates a recheck target that depends on all,
From: |
Mathieu Lirzin |
Subject: |
bug#26471: Automake 1.15 generates a recheck target that depends on all, breaking parallel builds |
Date: |
Thu, 13 Apr 2017 15:52:41 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) |
Hi Seth,
Seth Fowler <address@hidden> 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