Re: cygwin/mingw: do not lie about hardcoding

[Eric Blake]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Ralf, Bob,

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.

According to Bob Friesenhahn on 9/6/2006 7:51 AM:
>> But that is the search order for native windows .dlls and LoadModule.
>> Cygwin dlopen(), on the other hand, strives for Linux compatibility, and
>> has tricks up its sleeve to override the Windows default search path with
>> one that is more similar to Linux shared library lookup.  So I'm not sure
>> whether this TODO is mingw only, instead of cygwin/mingw.
> 
> Are you saying that Cygwin supports LD_LIBRARY_PATH?

Yes, but only for dlopen, not LoadModule.

> 
> Cygwin programs are obviously originally located using Cygwin-supplied
> rules (due to the Unix-style shell).  Does Cygwin also handle
> locating/loading all of the DLLs that the application depends on? Doing
> so would require special static startup ("crt") code for Cygwin
> applications which knows how to evaluate dependencies and load DLLs
> since otherwise normal Windows rules would apply.  My understanding is
> that most (all?) Cygwin code resides in a single DLL.  The fact that
> Cygwin installs DLLs in the executable 'bin' directories strongly
> suggests that there is no special startup code and that Windows handles
> the DLL loading using its own rules.

All cygwin executables link against a single cygwin1.dll, and that dll is
what implements dlopen.  Charles Wilson would be a better person to ask
here (he maintains the cygwin distribution of libtool), but although I
assume he subscribes to this list, he tends to have less time than me to
answer cygwin library-related questions.

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.

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.

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

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.

- --
Life is short - so eat dessert first!

Eric Blake             address@hidden
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.1 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFFABMW84KuGfSFAYARAuhoAJ9Q05lMOm9lRYdEmRq7X8aMva4gOACfaHjo
NORcCkV2BLSd4YU5ofSWa+I=
=AUMK
-----END PGP SIGNATURE-----