This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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
diff -u -r1.1.2.3 ltmain.m4sh
--- ltmain.m4sh 5 Oct 2004 04:15:28 -0000
+++ 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).


Unsubscribe info:
Problem reports:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]