This is the mail archive of the
cygwin
mailing list for the Cygwin project.
Re: libtool bug
[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/