[Top][All Lists]

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

FYI: libtool patch from gettext

From: Ralf Wildenhues
Subject: FYI: libtool patch from gettext
Date: Wed, 24 Aug 2005 18:00:48 +0200
User-agent: Mutt/1.4.1i

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/ (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/ (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>.
> > 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

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

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


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

        * libltdl/config/ (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
              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; }; })"

reply via email to

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