[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: hard link bug in libtool

From: Bob Friesenhahn
Subject: Re: hard link bug in libtool
Date: Wed, 18 Dec 2002 10:46:24 -0600 (CST)

Hard links are used to implement the lock because creating a hard-link
is normally an atomic operation.  Creating symbolic links is not an
atomic operation.

A better fix would be to add an algorithm which determines if locking
via hard-links works properly on the target filesystem.


On Wed, 18 Dec 2002, Mark Nejedlo wrote:

> There is a problem in libtool regarding using hard links for locking.  If
> there is a mount point in between the lock file location and the location
> of the libtool script (unlikely, but possible), the attempt to create a
> hard link will fail, causing an infinite loop waiting for the link to be
> created.  The problem is more severe when libtool is being used in AFS
> because every subdirectory in AFS is treated as a mount point with respect
> to hard links.  Since libtool apparently already checks if it should use
> symlinks by setting the variable LN_S, the patch to fix should be a
> trivial change in ltmain.in, included below as a diff -u5 against 1.4.2,
> which is what I have handy.  According to address@hidden the problem
> still exists in the libtool CVS tree.  Also below is the text of my bug
> report to lyx, which is where I first noticed the bug.  It may have
> additional useful information.  Thanks
> Mark
> diff -u5 ltmain.in ~/ltmain.in
> --- ltmain.in   Wed Oct 24 15:34:16 2001
> +++ /home/nejedlo/ltmain.in     Wed Dec 18 10:06:50 2002
> @@ -485,11 +485,11 @@
>      fi
>      # 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 $run ln "$0" "$lockfile" 2>/dev/null; do
> +      until $run $LN_S "$0" "$lockfile" 2>/dev/null; do
>         $show "Waiting for $lockfile to be removed"
>         sleep 2
>        done
>      elif test "$need_locks" = warn; then
>        if test -f "$lockfile"; then
> http://bugzilla.lyx.org/show_bug.cgi?id=775
>            Summary: libtool locks will never work in AFS
>            Product: LyX
>            Version: 1.2.1
>           Platform: PC
>         OS/Version: Linux
>             Status: UNCONFIRMED
>           Severity: minor
>           Priority: P2
>          Component: build
>         AssignedTo: address@hidden
>         ReportedBy: address@hidden
>          QAContact: address@hidden
> I am attempting to compile lyx 1.2.1 in AFS, and the make process enters
> an infinite loop when trying to compile src/mathed/textpainter.C with the
> error message "Waiting for textpainter.o.lock to be removed".  I deleted
> the error redirection of the ln line (approx. line 773, "until $run ln
> \"$0\" \"$lockfile\" 2>/dev/null; do") in the libtool at the root of the
> source tree and got the error message "ln: creating hard link
> `textpainter.o.lock' to `../../libtool': Invalid cross-device link".
> Because of how AFS works, it is not possible to create hard links between
> files in separate directories, this is the error that occurs when you try.
> I changed the "ln" to "ln -s" and it seems to work fine.  Interestingly,
> when looking through libtool, I found the lines:
> # Whether we need hard or soft links.
> LN_S="ln -s"
> at about line 75.  This was on a host running RedHat 7.3 and OpenAFS
> 1.2.4.
> --
> Mark Nejedlo            address@hidden
> 2328 Sterling Hall      (608) 262-7578
> 1150 University Avenue
> Madison, WI 53706-1390
> _______________________________________________
> Bug-libtool mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/bug-libtool

Bob Friesenhahn

reply via email to

[Prev in Thread] Current Thread [Next in Thread]