FYI: libtool patch from gettext

[Ralf Wildenhues]

Hi Bruno,

* Bruno Haible wrote on Wed, Aug 24, 2005 at 04:39:57PM CEST:
> Ralf Wildenhues wrote:
> >
> > 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.

ACK.  I have applied that to all branches.

> > 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>.
*snip*
> > 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.

Wow.  I had not thought of that possibility.
This patch deserves a more thorough explanation.

> This is the patch:
*snip patch*

Yep, I knew the patch, thanks.

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

Atomic in the sense that it uses only one executable: yes.
I had found one message about wanting as little time where the symlink
was not available, and figured that, since unlink() and link() are still
two separate syscalls, there was not much gain.

I have applied the patch below to all branches, which should hopefully
make the reason for this change clear.

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

Yep, I remembered that message.  It's not the only bug report about
this.  The fix isn't as trivial.

Cheers,
Ralf

2005-08-24  Bruno Haible  <address@hidden>

        * libltdl/config/ltmain.sh (func_mode_install): Try "ln -s -f"
        and "rm -f && ln -s" to make a symlink for a shared library: the
        former is needed for libraries `ln' depends on, the latter for
        Solaris /bin/ln.
        Reported by Nelson H. F. Beebe <address@hidden>.

Index: libltdl/config/ltmain.m4sh
===================================================================
RCS file: /cvsroot/libtool/libtool/libltdl/config/ltmain.m4sh,v
retrieving revision 1.3
diff -u -r1.3 ltmain.m4sh
--- libltdl/config/ltmain.m4sh  24 Aug 2005 14:49:23 -0000      1.3
+++ libltdl/config/ltmain.m4sh  24 Aug 2005 15:34:31 -0000
@@ -1911,10 +1911,13 @@
 
          if test "$#" -gt 0; then
            # Delete the old symlinks, and create new ones.
+           # Try `ln -sf' first, because the `ln' binary might depend on
+           # the symlink we replace!  Solaris /bin/ln does not understand -f,
+           # so we also need to try rm && ln -s.
            for linkname
            do
              test "$linkname" != "$realname" \
-               && func_show_eval "(cd $destdir && $RM $linkname && $LN_S 
$realname $linkname)"
+               && func_show_eval "(cd $destdir && { $LN_S -f $realname 
$linkname || { $RM $linkname && $LN_S $realname $linkname; }; })"
            done
          fi