Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Message-ID: <41687EAA.3080100@cwilson.fastmail.fm>
Date: Sat, 09 Oct 2004 20:13:30 -0400
From: Charles Wilson <cygwin AT cwilson DOT fastmail DOT fm>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040616 MultiZilla/1.6.4.0b
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Cc: Libtool Patches <libtool-patches AT gnu DOT org>
Subject: Re: libtool bug
References: <16741 DOT 49587 DOT 333388 DOT 685699 AT byrd DOT xs4all DOT nl> <1968842951 DOT 20041008015659 AT familiehaase DOT de> <41662639 DOT 3030306 AT cwilson DOT fastmail DOT fm> <87d5zt4r3g DOT fsf AT peder DOT flower> <657467259 DOT 20041008123554 AT familiehaase DOT de> <41671F91 DOT 8020508 AT cwilson DOT fastmail DOT fm>
In-Reply-To: <41671F91.8020508@cwilson.fastmail.fm>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

[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

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/