Que etapas você pode tomar para garantir ambientes sãos de compilação ao compilar software?

Question

Eu estou tendo um tempo horrível para obter um software para compilar em uma caixa do CentOS, e o problema que listei abaixo é específico, mas eu espero que a abordagem correta que vem do problema seja aquela que pode ser aplicado a problemas semelhantes, pois isso não parece ser específico para apenas este software. Chegando ao ponto embora ...

Eu estive preso com um problema de compilação ao construir uma máquina virtual padronizada no CentOS 5.4, e eu estou no escuro aqui a respeito de a) por que esse erro está ocorrendo eb) como corrigi-lo e a esperança de que alguém tropeça nesse problema também, espero que alguém possa me ajudar a encontrar a solução aqui.

Estou recebendo um erro configure: error: newly created file is older than distributed files! ao tentar compilar o Ruby Enterprise como abaixo, quando tento executar o instalador e as soluções oferecidas nos fóruns (de verificar o dente e tocar nos arquivos para atualizar o tempo associados a eles) não parecem estar ajudando aqui.

Que passos posso dar para descobrir qual a causa deste problema?

[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

Esta é uma máquina virtual em execução no VirtualBox, e a hora do host e da máquina virtual são idênticas e atualizadas. Eu também tentei executar isso depois de atualizar o tempo com um cliente ntp, então não adiantou. Eu tentei isso depois de ler este post aqui de alguém tendo um problema semelhante

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

A outra abordagem que tentei é tocar no nível superior dos arquivos na pasta de compilação como sugerido aqui , mas isso também não funcionou (para ser honesto, não sei por que teria funcionado também)

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

Não tenho certeza do que posso fazer a seguir aqui - o problema parece ser o script de configuração bash que retorna este erro error: newly created file is older than distributed files! , na linha: 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

o que torna isso realmente frustrante é que esse script funciona algumas vezes, quando a VM está em funcionamento há uma hora ou mais, mas não na inicialização. Não há nada que eu veja no crontab que sugira que quaisquer tarefas por hora sejam executadas, o que pode mudar o estado do sistema, o suficiente para fazer a diferença para esse script funcionar.

Eu estou totalmente em uma perda quando se trata de depuração além daqui. Qual é a melhor abordagem para levar aqui?

Obrigado

    

Answer 1

Hoje experimentei exatamente esse problema em uma caixa recém-instalada durante a instalação do ree-1.8.7-2011.03.

Depois de configurar o ntpd, verificando o relógio do hardware e excluindo problemas reais com o relógio, a mensagem de erro ainda persistia. Finalmente, rastreei esse erro no diretório google-perftools . Depois de tocar no script configure , o problema acabou de ser resolvido e o Ruby Enterprise Edition foi instalado sem qualquer problema.

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

    

Answer 2

A "verificação de sanidade de datas" nesse script de shell de configuração parece borked para mim, precisa ser corrigido. Veja isto:

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

Portanto, ele toca em um arquivo e, em seguida, tenta descobrir se o seu mtime é mais recente que o mtime de $srcdir/configure e faz isso invocando ls e comparando a saída com uma string fixa. Os autores escrevem

  # 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".

mas eu acho que isso é lixo. Existem muitas versões / sabores de ls e maneiras de alterar a saída de ls '(até mesmo um nome) para ter certeza sobre o formato de saída ls '.

De qualquer forma, há formas muito mais elegantes de se fazer isso. Por exemplo. no bash (veja 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

Ou descubra se algum mtime está no futuro diretamente!

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

ou

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

Agora escreva o patch você mesmo: -)

    

Answer 3

Você não fala muito sobre o desempenho do seu relógio do sistema. Em vez de olhar para o problema da compilação, que tal testar o desempenho do relógio do sistema? O NTP pode ajudar com a deriva do relógio, mas não corrigirá algo errático. Se o clock do hardware for interrompido, você pode precisar de uma nova placa-mãe. Aqui está um teste que pode ajudar:

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

Isso deve produzir a data exatamente a cada minuto. Se a saída não se parece com o abaixo:

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

então você tem um problema de relógio de hardware. Lutando com isso ferramentas como o NTP podem não funcionar. Hardware é a melhor solução se você tem um problema de hardware.