libtool locking issue (was: [patch 00/19] @patch@ Queue)

[Ralf Wildenhues]

Hi Gary,

* Gary V. Vaughan wrote on Mon, Oct 10, 2005 at 04:45:14PM CEST:
> Ralf Wildenhues wrote:
> >
> >Wow.  I'm quite impressed!  8-)
> 
> Amazing what one can do when locked in a room for a weekend with
> nothing but an internet connection, and a fully stocked fridge!

I thought arch can do without internet connection.  Surely for me it
would improve throughput to be without connection then..  ;-)

> >>Looking forward to making the alpha release,
> >
> >Yep, me too.  I've got a handful of own patches sitting here, which I'd
> >like to push out before, but I'll probably agree to drop anything that
> >will cost me more than a couple of days to push out.
> 
> Sure thing.
> 
> I'm afraid I don't understand the locking problem cited as the
> last release blocking issue on the kicks-ass RoadMap, otherwise
> I would have tackled that one too.

I'm almost inclined to ignore it for the release.

One example of it goes as follows: User uses
  LIBTOOL = /usr/bin/libtool 
in his Makefile.  That `libtool' has 
  need_locks=yes
Now, the build tree is below a different mount point than /usr.

This code in ltmain:
|  # Lock this critical section if it is needed
|  # We use this script file to make the link, it avoids creating a new file
|  if test "$need_locks" = yes; then
|    until $opt_dry_run || ln "$progpath" "$lockfile" 2>/dev/null; do
|      func_echo "Waiting for $lockfile to be removed"
|      sleep 2
|    done
|  elif test "$need_locks" = warn; then

will then deadlock.

Or, instead of /usr/bin/libtool, LIBTOOL points inside some build tree
of a different but related package (as I believe was in the bug report).

Point is, it's actually nontrivial to assume any file name in the build
tree to certainly be present, unless you also accept to create $OBJDIR
in any case.  And then you still need to be careful to do that, too.
See the referenced mail for more thoughts about a solution.

This issue is much less likely to actually hit anyone since the
boilerplate patches are in place.

Cheers,
Ralf