[Top][All Lists]

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

Re: libtool patch from gettext

From: Bruno Haible
Subject: Re: libtool patch from gettext
Date: Wed, 24 Aug 2005 16:39:57 +0200
User-agent: KMail/1.5

Ralf Wildenhues wrote:
> The first one below I'd like to apply: return error from cwrapper if
> exec*() failed (all branches).
> 2003-11-27  Bruno Haible  <address@hidden>
>         * config/ (cwrappersource): return 127 if exec failed.

Yes, that matches the standard convention about exit code 127.

> Bruno, I believe your original ChangeLog entry for another patch is
> wrong: it said
> | * config/ (install): Use "ln -s -f" instead of
> | "rm -f && ln -s" to make a symlink for a shared library. Take
> | care of Solaris /bin/ln.
> | Reported by Nelson H. F. Beebe <address@hidden>.
> I have searched whatever I could find, and all I could find was a
> request to try `ln -sf' before `rm -f && ln -s' in order to minimize
> the time that the symlink would not be available, and no issue connected
> with Solaris ln.  Can you enlighten us on this, so we can mention it in
> the Autoconf Portability section?
> Otherwise, I don't see much sense in replacing a race condition with a
> slightly smaller race condition.

This patch (actually it were two patches that were merged into one)
is not about a race condition. It's about the ability to use libtool for
installing, in an environment where the "rm" and "ln" programs
in PATH are linked against

This is the patch:

*** libtool-1.5.14/    2005-02-12 13:30:57.000000000 +0100
--- gettext/build-aux/ 2005-05-20 22:53:22.000000000 +0200
*** 5565,5572 ****
            for linkname
              if test "$linkname" != "$realname"; then
!               $show "(cd $destdir && $rm $linkname && $LN_S $realname 
!               $run eval "(cd $destdir && $rm $linkname && $LN_S $realname 
--- 5572,5579 ----
            for linkname
              if test "$linkname" != "$realname"; then
!               $show "(cd $destdir && { $LN_S -f $realname $linkname || { $rm 
$linkname && $LN_S $realname $linkname; }; })"
!               $run eval "(cd $destdir && { $LN_S -f $realname $linkname || { 
$rm $linkname && $LN_S $realname $linkname; }; })"

In the original version

    $rm $linkname && $LN_S $realname $linkname

"rm" removes, and "ln" cannot then execute because its runtime
dependencies are broken. So I first changed this to

    $LN_S -f $realname $linkname

to make the removal and link creation a combined. atomic operation. This,
however, didn't work with Solaris /bin/ln, which doesn't understand
"ln -s -f". Therefore I changed it to

    $LN_S -f $realname $linkname || { $rm $linkname && $LN_S $realname 
$linkname; }

The first part is atomic, for when "ln" is linked with; the
second part is the fallback for vendors' native "ln" programs.

> The third patch I found was one where with `chmod 777 .libs'.  I'd like
> to fix relinking output in $DESTDIR/$prefix instead.

Yes, this seems right. See also


reply via email to

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