[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
libtool locking issue (was: [patch 00/19] @patch@ Queue)
From: |
Ralf Wildenhues |
Subject: |
libtool locking issue (was: [patch 00/19] @patch@ Queue) |
Date: |
Mon, 10 Oct 2005 17:10:21 +0200 |
User-agent: |
Mutt/1.5.11 |
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
- Re: [patch 04/19] 286-gary-libtoolize-recursive-ltdl.diff Queue, (continued)
- Re: [patch 04/19] 286-gary-libtoolize-recursive-ltdl.diff Queue, Ralf Wildenhues, 2005/10/11
- Re: [patch 04/19] 286-gary-libtoolize-recursive-ltdl.diff Queue, Gary V. Vaughan, 2005/10/13
- Re: [patch 04/19] 286-gary-libtoolize-recursive-ltdl.diff Queue, Gary V. Vaughan, 2005/10/14
- Re: [patch 04/19] 286-gary-libtoolize-recursive-ltdl.diff Queue, Ralf Wildenhues, 2005/10/16
- 286-gary-libtoolize-recursive-ltdl.diff, Gary V. Vaughan, 2005/10/17
- Re: 286-gary-libtoolize-recursive-ltdl.diff, Ralf Wildenhues, 2005/10/18
- Re: 286-gary-libtoolize-recursive-ltdl.diff, Gary V. Vaughan, 2005/10/18
- Re: 286-gary-libtoolize-recursive-ltdl.diff, Ralf Wildenhues, 2005/10/24
Re: [patch 00/19] @patch@ Queue, Ralf Wildenhues, 2005/10/10