libtool-patches
[Top][All Lists]
Advanced

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

cygwin/mingw: do not lie about hardcoding


From: Ralf Wildenhues
Subject: cygwin/mingw: do not lie about hardcoding
Date: Wed, 6 Sep 2006 07:46:44 +0200
User-agent: Mutt/1.5.13 (2006-08-11)

This is a new TODO item.

The w32 support in Libtool currently lies about their hardcoding
capabilities by setting hardcode_libdir_flag_spec to a nonempty value.
This makes ltmain think that it can hardcode this way.

This needs to be fixed.  One result of this is that, if you use -static,
libtool fails to create a wrapper for uninstalled programs linked
against uninstalled libraries.  This breaks a test in static.at.

But fixing this issue requires to change ltmain logic a bit: if we just
changed the hardcode_libdir_flag_spec setting, then ltmain would barf in
situations where it would like to add hardcoding for installed outputs.
Well, not possible, but also there are features of w32 DLL searching
that libtool currently doesn't know about explicitly: that bindir is
searched first.  More generally, the search order is:

- the directory of the current executable,
- the current directory,
- the w32 system directory (GetSystemDirectory returns this),
- the w32 directory (GetWindowsDirectory returns this),
- directories in PATH.

And since we do the symlinking to $libdir/../bin/foo.dll, ltmain should
also take _that_ into account and not warn if all libraries live there.
If libraries live where we deem them unreachable (or only reachable by
current PATH settings), then I think ltmain should warn, but not fail.

BTW, this bug has been part of Libtool ever since Ian's original port in
1998-11-04 (revision 1.13 of ltconfig.in).

Cheers,
Ralf




reply via email to

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