[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/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