libtool-patches
[Top][All Lists]
Advanced

[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/ltmain.sh (cwrappersource): return 127 if exec failed.

Yes, that matches the standard convention about exit code 127.
http://www.opengroup.org/onlinepubs/009695399/functions/posix_spawn.html
http://www.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html#tag_02_08_02

> Bruno, I believe your original ChangeLog entry for another patch is
> wrong: it said
>
> | * config/ltmain.sh (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 libintl.so, in an environment where the "rm" and "ln" programs
in PATH are linked against libintl.so.

This is the patch:

*** libtool-1.5.14/ltmain.sh    2005-02-12 13:30:57.000000000 +0100
--- gettext/build-aux/ltmain.sh 2005-05-20 22:53:22.000000000 +0200
***************
*** 5565,5572 ****
            for linkname
            do
              if test "$linkname" != "$realname"; then
!               $show "(cd $destdir && $rm $linkname && $LN_S $realname 
$linkname)"
!               $run eval "(cd $destdir && $rm $linkname && $LN_S $realname 
$linkname)"
              fi
            done
          fi
--- 5572,5579 ----
            for linkname
            do
              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; }; })"
              fi
            done
          fi

In the original version

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

"rm" removes libintl.so, 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 libintl.so; 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
http://lists.gnu.org/archive/html/libtool/2005-07/msg00115.html

Bruno





reply via email to

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