Re: libtool bug

[Charles Wilson]

[CC:ed to libtool-patches list]

Background for the libtool-patches guys:  Question revolves around a 
problem with relinking executables (and DLLs which depend on other 
uninstalled DLLs, actually) when installing stuff on cygwin.  There are 
actually two problems; only the first is addressed here -- why do we 
relink stuff on installation on cygwin anyway?  There's nothing in the 
DLLs or EXEs that encodes an -rpath, so what's the point?  I tried the 
following patch:

Index: ltmain.m4sh
===================================================================
RCS file: /cvsroot/libtool/libtool/config/ltmain.m4sh,v
retrieving revision 1.1.2.3
diff -u -r1.1.2.3 ltmain.m4sh
--- ltmain.m4sh 5 Oct 2004 04:15:28 -0000       1.1.2.3
+++ ltmain.m4sh 9 Oct 2004 23:21:21 -0000
@@ -3539,10 +3539,17 @@
        link_static=no # Whether the deplib will be linked statically
        if test -n "$library_names" &&
           { test "$prefer_static_libs" = no || test -z "$old_library"; 
}; then
-         if test "$installed" = no; then
-           notinst_deplibs="$notinst_deplibs $lib"
-           need_relink=yes
-         fi
+         case $host in
+         *cygwin* | *mingw*)
+             # No point in relinking DLLs because paths are not encoded
+           ;;
+         *)
+           if test "$installed" = no; then
+             notinst_deplibs="$notinst_deplibs $lib"
+             need_relink=yes
+           fi
+           ;;
+         esac
          # This is a shared library

          # Warn about portability, can't link against -module's on some

(I also tried setting notinst_deplibs to "$notinst_deplibs $lib" as 
before, but setting need_relink=no, with similar results).

Charles Wilson wrote:

> Not entirely true.  With your change (or one very similar), all of the 
> *-exec.tests in the libtool test suite failed.  These tests attempt to 
> run the uninstalled executable.  I'm not sure why; it's probably a side 
> effect of the change, not just "relinking" itself.  Investigating...

Okay, with the change, the executables are put into the build directory 
(not into the .libs/ subdir, which is where they OUGHT to go) and there 
is no wrapper exec, no wrapper shell script.  So, during the test, the 
$PATH doesn't get set properly, and the executable can't find the 
uninstalled DLLs it needs.

Whether to set the $PATH and produce wrapper scripts is clearly a 
distinct issue from "should stuff be relinked on install" -- although on 
platforms which encode -rpaths into sharedlibs and executables one issue 
will affect the other.

Not true on cygwin.

These two questions (need wrappers to set PATH/LD_LIBRARY_PATH/etc, vs. 
need to relink on install) should be disentangled.  On cygwin, we need 
wrappers, but not relink.  On most OTHER platforms, you probably need 
relink (but no wrappers?) IF using rpath; you need wrappers (and 
relink?) if you are NOT using rpath.  Confusing, no?

(Libtool-patches list: the "second problem" alluded to above, is that 
the relink itself fails in a particular case.  Still tracking that one 
down; may be unrelated, or a false alarm).

--
Chuck