bug-libtool
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: libtool-2.4, cygwin: Odd failures


From: Ralf Wildenhues
Subject: Re: libtool-2.4, cygwin: Odd failures
Date: Fri, 24 Sep 2010 07:26:13 +0200
User-agent: Mutt/1.5.20 (2010-08-04)

Hi Charles,

* Charles Wilson wrote on Fri, Sep 24, 2010 at 01:18:45AM CEST:
>  86: compiling copied libltdl          FAILED (standalone.at:49)
>  87: installable libltdl               FAILED (standalone.at:66)
>  88: linking libltdl without autotools FAILED (standalone.at:83)
> 
> Subproject Libltdl.
>  92: linking libltdl without autotools FAILED (subproject.at:113)
> 
> 108: --with-ltdl-include/lib           FAILED (configure-iface.at:178)
> 
> 
> In each case, the issue was (similar to) the following:
> 
> ../../libtool-2.4/tests/standalone.at:49: : ${CONFIG_SHELL=/bin/sh};
> export CONFIG_SHELL;         $CONFIG_SHELL ./configure $configure_options
> stderr:
> configure: error: newly created file is older than distributed files!
> Check your system clock

Can you send detailed ls output including full time stamps, right after
the above failure, for the following directories:
  top_srcdir
  top_srcdir/libltdl
  builddir/tests/testsuite.dir/086

plus the time at which you ran the test.  Thanks.

> Now, AFAIK there is nothing wrong with my system clock; I was able to
> get 100% test success on the same machine, just a while back at
> 254f5280e (Sep 16).

FWIW, I've seen issues with some of these tests as well, but they didn't
fail with this particular warning.

> Also, if I re-run the failing tests without changing anything else,
> 86-88 will pass, but 92,108 won't.  Rerunning 92,108 a *third* time
> allows them to pass.  After that, all five "failing" tests will continue
> to pass.

Well, but *that* is something that typically happens when your system
clock really was not quite right: after a while, no more files have time
stamps in the future, then everything starts to work.

Not saying that this has to be the case here, but it sure is an
indicator.

> This smells to me like somewhere the dependency order got screwed up, so
> that after several re-build attempts, finally the configure scripts are
> stable, and will "match" without triggering the error above.

Another possibility, yes.

> I'll submit the build logs for the "pristine" 2.4 case on cygwin, with
> the five failures, in a little while.

Thanks,
Ralf



reply via email to

[Prev in Thread] Current Thread [Next in Thread]