What steps can you take to ensure sane build environments when compiling software?

Question

I'm having a horrible time getting a piece of software to compile on a CentOS box, and the problem I've listed below is specific, but I'm hoping the correct approach that comes out of this is one that can be applied to similar problems, as this doesn't seem to be one that's specific to just this piece of software. Getting to the point though...

I've been stuck with a compilation problem when building a standardised virtual machine on CentOS 5.4, and I'm in the dark here as to a) why this error is occurring, and b) how to fix it, and in the hope that someone else stumbles across this problem too, I'm hoping someone can help me find the solution here.

I'm getting a configure: error: newly created file is older than distributed files! error when trying to compile Ruby Enterprise like below when I try to run the installer, and the solutions offered to on the forums (of checking the tine, and touching the files to update the time associated with them) don't seem to be helping here.

What steps can I take to work out what the cause of this problem?

[vagrant@vagrant-centos-5 ruby-enterprise-1.8.7-2009.10]$ sudo ./installer
Welcome to the Ruby Enterprise Edition installer
This installer will help you install Ruby Enterprise Edition 1.8.7-2009.10.
Don't worry, none of your system files will be touched if you don't want them
to, so there is no risk that things will screw up.

You can expect this from the installation process:

  1. Ruby Enterprise Edition will be compiled and optimized for speed for this
     system.
  2. Ruby on Rails will be installed for Ruby Enterprise Edition.
  3. You will learn how to tell Phusion Passenger to use Ruby Enterprise
     Edition instead of regular Ruby.

Press Enter to continue, or Ctrl-C to abort.

Checking for required software...

 * C compiler... found at /usr/bin/gcc
 * C++ compiler... found at /usr/bin/g++
 * The 'make' tool... found at /usr/bin/make
 * Zlib development headers... found
 * OpenSSL development headers... found
 * GNU Readline development headers... found
--------------------------------------------
Target directory

Where would you like to install Ruby Enterprise Edition to?
(All Ruby Enterprise Edition files will be put inside that directory.)

[/opt/ruby-enterprise] : 
--------------------------------------------
Compiling and optimizing the memory allocator for Ruby Enterprise Edition
In the mean time, feel free to grab a cup of coffee.

./configure --prefix=/opt/ruby-enterprise --disable-dependency-tracking
checking build system type... i686-pc-linux-gnu
checking host system type... i686-pc-linux-gnu
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... configure: error: newly created file is older than distributed files!
Check your system clock

This is a virtual machine running on virtualbox, and the time of the host and the virtual machine are identical, and up to date. I've also tried running this after updating time with an ntp-client, so no avail. I tried this after reading this post here of someone having a similar problem

[vagrant@vagrant-centos-5 ruby-enterprise-1.8.7-2009.10]$ date
Tue Apr 27 08:09:05 BST 2010 

The other approach I've tried is to touch the top level the files in the build folder like suggested here, but this hasn't worked either (an to be honest, I'm not sure why it would have worked either)

[vagrant@vagrant-centos-5 ruby-enterprise-1.8.7-2009.10]$ sudo touch ruby-enterprise-1.8.7-2009.10/*

I'm not sure what I can do next here - the problem seems to be the bash configure script that returns this error error: newly created file is older than distributed files!, at line :2214

{ echo "$as_me:$LINENO: checking whether build environment is sane" >&5
echo $ECHO_N "checking whether build environment is sane... $ECHO_C" >&6; }
# Just in case
sleep 1
echo timestamp > conftest.file
# Do `set' in a subshell so we don't clobber the current shell's
# arguments.  Must try -L first in case configure is actually a
# symlink; some systems play weird games with the mod time of symlinks
# (eg FreeBSD returns the mod time of the symlink's containing
# directory).
if (
   set X `ls -Lt $srcdir/configure conftest.file 2> /dev/null`
   if test "$*" = "X"; then
      # -L didn't work.
      set X `ls -t $srcdir/configure conftest.file`
   fi
   rm -f conftest.file
   if test "$*" != "X $srcdir/configure conftest.file" \
      && test "$*" != "X conftest.file $srcdir/configure"; then

      # If neither matched, then we have a broken ls.  This can happen
      # if, for instance, CONFIG_SHELL is bash and it inherits a
      # broken ls alias from the environment.  This has actually
      # happened.  Such a system could not be considered "sane".
      { { echo "$as_me:$LINENO: error: ls -t appears to fail.  Make sure there is not a broken
alias in your environment" >&5
echo "$as_me: error: ls -t appears to fail.  Make sure there is not a broken
alias in your environment" >&2;}
   { (exit 1); exit 1; }; }
   fi
   ### PROBLEM LINE ####
   # this line is the problem line - this is returned true, sometimes it isn't and I can't 
   # see a pattern that that determines when this will test will pass or not.
   test "$2" = conftest.file
   )
then
   # Ok.
   :
else
   { { echo "$as_me:$LINENO: error: newly created file is older than distributed files!
Check your system clock" >&5
echo "$as_me: error: newly created file is older than distributed files!
Check your system clock" >&2;}
   { (exit 1); exit 1; }; }
fi

the thing that makes this really frustrating is that this script works sometimes, when the VM has been running for an hour or so it works, but not at boot. There's nothing I see in the crontab that suggests any hourly tasks are run that might change the state of the system enough make a difference to this script working.

I'm totally at a loss when it comes to debugging beyond here. What's the best approach to take here?

Thanks

Answer 1

Today I experienced exactly this problem on a newly installed box while installing ree-1.8.7-2011.03.

After configuring ntpd, checking the hardware clock and excluding actual problems with the clock and tima the error message still persisted. Finally I traced down this error to the included google-perftools directory. After touching that configure script, the problem just resolved and Ruby Enterprise Edition installed without any problem.

[mark@host347 ~]$ cd src/ree-1.8.7-2011.03/source/
[mark@host347 source]$ touch ./distro/google-perftools-1.7/configure

Answer 2

The "date sanity check" in that configure shell script looks borked to me, it needs fixing. Look at this:

echo timestamp > conftest.file
# Do `set' in a subshell so we don't clobber the current shell's
# arguments.  Must try -L first in case configure is actually a
# symlink; some systems play weird games with the mod time of symlinks
# (eg FreeBSD returns the mod time of the symlink's containing
# directory).
if (
   set X `ls -Lt $srcdir/configure conftest.file 2> /dev/null`
   if test "$*" = "X"; then
      # -L didn't work.
      set X `ls -t $srcdir/configure conftest.file`
   fi
   rm -f conftest.file
   if test "$*" != "X $srcdir/configure conftest.file" \
      && test "$*" != "X conftest.file $srcdir/configure"; then

So it touches a file and then tries to find out whether its mtime is newer than the mtime of $srcdir/configure, and is does so by invoking ls and then comparing the output to a fixed string. The authors write

  # If neither matched, then we have a broken ls.  This can happen
  # if, for instance, CONFIG_SHELL is bash and it inherits a
  # broken ls alias from the environment.  This has actually
  # happened.  Such a system could not be considered "sane".

but i think that is rubbish. There are too many versions/flavours of ls and ways to alter ls' output (they even name one) to be sure about ls' output format.

Anyway, there are way more elegant ways of doing this. E.g. in bash (see help test):

if [ $FILE1 -nt $FILE2 ] ; then
    echo "$FILE1 is newer than $FILE2"
elif [ $FILE2 -nt $FILE1 ] ; then
    echo "$FILE2 is newer than $FILE1"
else
    echo "$FILE1 and $FILE2 are equally new"
fi

Or find out whether some mtime is in the future directly!

find -L $FILE -newermt now -exec echo THE FILE {} IS COMING FROM THE FUTURE \;

or

find -L $FILE -mtime -0 -exec echo THE FILE {} IS COMING FROM THE PRESENT OR THE FUTURE \;

Now write the patch yourself :-)

Answer 3

You don't talk much about your system clock performance. Rather than looking at the compile issue, how about testing the system clock performance? NTP can help with clock drift, but it won't fix something erratic. If the hardware clock is busted, you might need a new motherboard. Here is a test that might help:

for i in `seq 1 60`
do
date
sleep 60
done

This should output the date exactly every minute. If the output does not look like the below:

    Tue Apr 27 13:33:28 ADT 2010
    Tue Apr 27 13:34:28 ADT 2010
    Tue Apr 27 13:35:28 ADT 2010
...

then you have a hardware clock problem. Fighting it with tools like NTP might not work. Hardware is the best fix if you have a hardware problem.