Re: [patch #3872] locking in libtool

[Ralf Wildenhues]

I am Cc:ing this to the libtool-patches list.  I showed you where it is
archived, its public archive mangles email addresses, and anyway the
patch posts on savannah are crossposted there.

I have reordered your mail for convenience.

* Marcin Siennicki wrote on Thu, Mar 31, 2005 at 12:19:55PM CEST:
>
> >Reply to this item at:
> >
> > <http://savannah.gnu.org/patch/?func=detailitem&item_id=3872>
> >
> Now I cannot get there because the item is private.

Yes, precisely.  I put it to private because _you_ requested to do so.
I am not changing this back, just keep this thread to libtool-patches
from now on, please.

> Ralf Wildenhues napisał(a):
> 
> >Did you actually encounter this in practise?  
> >
> Yes. While building apr-util (from apache) on Owl Linux the libtool
> hanged. But the problem was on my machine (I moved to gcc-3.4, and I
> had rpm macros with deprecated options, so I get:

OK.  Easiest workaround would be to remove these options.  There are
other tests which will give bogus output as well then.
(yes, all of them ought to be fixed eventually, I know..)

Does apr-util use a preinstalled libtool (like /usr/bin/libtool) or does
it build its own (like $top_builddir/libtool)?

Please answer all questions I asked, thank you.

> checking if gcc supports -c -o file.o... no
> checking if we can lock with hard links... yes
> 
> >I don't think your patch is ok as it is, because $LN_S may be `cp -p' and
> >thus won't fail if the file already exists.  The current code is not ok for
> >installed `libtool', however.
> 
> I don't think so, too :) The patch is just a simple way I used to
> avoid the problem, the simpler way was to set need_locks to no, but I
> realy didn't know if it did need them.  But the problem of hanging
> while locking still exists.

gcc has never needed this AFAIK.

I've looked a little, and this problem actually does kind of suck:

- can't think of a file we can reasonably `ln' from if the user uses
installed libtool (e.g., /usr/bin/libtool); $srcfile might be on another
file system as well.
- not sure whether changing the locking mechanism to just
    mkdir "$lockfile"
works on nfs (is both atomic and reliable), nor how ancient unices must
be to have non-atomic mkdir(3) (mknod plus link; V7 had this).
- if we changed to use mkdir, the new locking scheme will be
incompatible with the old one (we do `test -f "$lockfile"' right now).
It sounds pretty unlikely, but I can imagine source trees (consisting of
several subpackages) with different libtool versions trying to access
the same object file.

The last objection is kind of academic, the second I am uncertain about.
Furthermore, you can easily denial yourself service by creating the
lockfile by hand.

Suggestions appreciated.

Regards,
Ralf