Re: [PATCH] Atomic creation of fast-install relinked binary

[Ralf Wildenhues]

Hello Paolo,

* Paolo Bonzini wrote on Thu, Jul 31, 2008 at 02:39:10PM CEST:
> This patch fixes PR35752 in GCC.

(which is: <http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35752>).

> The problem is a race condition in the fast-install wrapper.  The  
> program could be called twice in a parallel make, with the second  
> invocation starting before the first invocation of the wrapper script  
> has finished relinking the executable.  In this case, the second  
> execution will fail.

There may be a race condition, or several.  First, it would be nice to
have a test, at least a probabilistic one.  I've tried

  make check TESTSUITEFLAGS=-V \
    "TESTS=tests/depdemo-shared.test tests/depdemo-make.test"
  cd tests/depdemo
  while ./depdemo & ./depdemo && wait; do
    rm -f .libs/lt-depdemo
  done

on GNU/Linux, but that did not expose anything.

Second, I don't see how your patch fixes a race that wasn't fixed
before: the code in ltmain.m4sh already has

    file=\"\$\$-\$program\"

[...]
      if relink_command_output=\`eval \$relink_command 2>&1\`; then :
[...]

    $MV \"\$progdir/\$file\" \"\$progdir/\$program\" 2>/dev/null ||
    { $RM \"\$progdir/\$program\";
      $MV \"\$progdir/\$file\" \"\$progdir/\$program\"; }

which should already take care of this particular issue.
And gcc/ltmain.sh has this, too.

Thanks for working on this!

Cheers,
Ralf

> 2008-07-31  Paolo Bonzini  <address@hidden>
> 
>       * libltdl/config/ltmain.m4sh: Set up the wrapper script's
>       relink_command so that it creates .libs/lt-NAME atomically.