libtool-patches
[Top][All Lists]
Advanced

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

Re: cygwin/mingw: do not lie about hardcoding


From: Charles Wilson
Subject: Re: cygwin/mingw: do not lie about hardcoding
Date: Thu, 14 Sep 2006 16:15:25 -0400
User-agent: Thunderbird 1.5.0.5 (Windows/20060719)

Eric Blake wrote:

According to Ralf:
So, then the question is where is the Cygwin semantics documented (for
both the link editor's behavior, as well as the runtime linker's) and
does it have a form of hardcoding as well?  And if yes, why are we not
using it?

I wish I knew this better.  You may have better luck asking (or searching)
the cygwin mailing list.


As far as I know, there is no support for any kind of hardcoding in the PEI386 format. And if there is, neither ld nor the win32 runtime loader support it.

Are you saying that Cygwin supports LD_LIBRARY_PATH?

Yes, but only for dlopen, not LoadModule.

Correct.

All cygwin executables link against a single cygwin1.dll, and that dll is
what implements dlopen.

Correct.


I think, but am not sure, that the reason that cygwin installs most dlls
in /bin is for the sake of pre-linked executables, where Windows rules
apply of searching the directory where the .exe resides first.  For
example, 'cygcheck /bin/bash' shows that bash is pre-linked against
cygwin1.dll, cygintl-3.dll, and cygreadline6.dll.  In those cases, Windows
rules apply for loading all subsidiary dlls prior to any cygwin startup
code running, and a missing or out-of-date dll pops up a modal dialog box
stating that an entry point could not be found.

Correct.

But for dynamic loads, cygwin is running before the dlopen call, so it can
use its own rules and honor LD_LIBRARY_PATH.  For example, I'm playing
with CVS M4, and by default, m4.exe links against cygwin1.dll,
cygintl-8.dll, m4-0.dll, traditional-0.dll, gnu-0.dll, and cygm4-0.dll,
but uses libltdl to load other libraries such as load-0.dll at runtme.
When installed, m4-0.dll must be found by the Windows rules before m4.exe
can be run; but load-0.dll can be installed anywhere else as long as
LD_LIBRARY_PATH points to it.

Correct. (Also, in the particular case of CVS m4, I think the executable "knows" about the installation path of its modules, so you only need to set LD_LIBRARY_PATH if you've moved the modules to a different location after installing)

Lastly, does libtool now use Cygwin's dlopen()?

Yes, it does. /usr/bin/cygltdl-3.dll imports dlopen and does not import LoadLibrary.

If it doesn't, that is a bug; and the issue has been discussed in the list
archives in the past.  There are too many cygwin pitfalls when using
LoadModule instead of dlopen; by using raw Windows API, you are going
behind cygwin's back, and cygwin can no longer track what you are doing.
That is not to say that LoadModule can't work on cygwin, but that libtool
on cygwin should default to dlopen unless specifically configured
otherwise by a knowledgeable user.

Correct.

Thanks for handling the heavy lifting, Erick.

--
Chuck




reply via email to

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