Re: automake 1.9.6 build failure

[Bob Proulx]

Mike Owens wrote:
> Ralf Wildenhues wrote:
> > Mike Owens wrote:
> > > I am maintaining my copy of automake in a subversion vendor branch. I
> > > have encountered a problem that is very difficult for me to diagnose.
> > > The copy in subversion will not build on Solaris. The tarball will.
> >
> > That's probably because the subversion copy has messed-up timestamps.
> > Try running
> >   ./bootstrap

Of course running the developer tools should work and can't be
recommended against.  But that also requires having all of the
developer tools available and at a sufficiently good version to build
that way.  For some cases this is not required and it can be simpler
to run the bundled configure tests only.

Because version control systems typically do not preserve the original
timestamps it is typical to force them to a known good state when this
is desired, such as when keeping a vendor branch.  The timestamp
ordering depends upon the package.  Basically what I do is to unpack
the tar image and then look at the relative time stamp ordering of the
generated files.  For automake something like this following, from
looking at the time ordering of automake-1.10 after a clean build.

  touch aclocal.m4 configure
  find . -name Makefile.in -print0 | xargs -r0 touch
  touch config.status aclocal

However at least one other poster with a similar question said that
was not sufficient for the project he was building.  Another possibly
simpler way is that you can always touch all of the files to the same
timestamp.  If they have the same timestamp then they will appear to
be up to date.  Something like this:

  find . -type f -print0 | xargs -r0 touch -r configure.ac

> > in it once.  Then, configure and make.  Then keep the build tree.
> > Then the next svn update may trigger another automake invocation,
> > but it should succeed now.  Hmm.  Maybe you also need to do a
> > 'make install' for 1.9.6 and keep the installed tree around, I
> > remember fixing a related bug before 1.10.

Personally I keep up new copies of the autotools and that is a good
solution.  But it is more work and in the case where this is not
needed doing the timestamp setting can avoid needing any of those
tools available.

> > > This problem does not occur on Linux -- the subversion checkout builds 
> > fine.
> >
> > Probably the difference is that when you do a new checkout, the time
> > stamps are ok, while on an updated svn tree, they won't be.

Probably differences in timing cause the working system checkout to be
fast enough that timestamps happen to be on the same second whereas on
the other non-working system the checkout is slow enough that
timestamps are skewed by more than a second.  In the former case this
makes things appear up to date.  In the latter case it makes things
appear as if they are out of date and need to be updated.

> That did it. I downloaded a copy of bootstrap from CVS and ran it.
> Everything worked fine after that. Thanks for your help.

I know that you already have a good solution.  I mostly posted this
for the mail archive for others that search for the same problem.

Bob