This is the mail archive of the cygwin-apps@cygwin.com 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: symlink dll


Max Bowsher schrieb:
Reini Urban wrote:
Max Bowsher schrieb:
Reini Urban wrote:
Max Bowsher schrieb:
Reini Urban wrote:

Shouldn't we then provide a cygperl5_8.dll symlinked to
cygperl5_8_5.dll
also (in linux fashion), and apps should link against cygperl5_8.dll
resp. a more generic libperl.dll.a then?
otherwise you'll have to recompile all dependent apps.

You are forgetting something. The Windows runtime linker (understandably) doesn't understand Cygwin symlinks.

But cygwin dlopen does understand symlinks. And perls dynalinker uses dlopen(cygpath), not LoadLibrary (fullpath). All other posix libs also use dlopen() not LoadLibrary(). And the cygwin dlopen() calls fullpath = get_full_path_of_dll(cygpath) which resolves links.

True, but entirely missing the point.


cygperlxxx.dll is also used by things doing "gcc -lperl", not dlopen or
LoadLibrary.


this search look for libperl.la or libperl.a.
and the for the .dll.a (by convention) if shared.

but simple path lookup in the .la file reader should resolve softlinks
also. binutils maintainer??

/lib/libxerxes-c25.dll.a also uses softlinks from libxerces-c.dll.a and
libxerces.dll.a

/bin/cygdb-41.dll.lnk is a softlink to /bin/cygdb-4.1.dll


Um, really? Not as part of the official package.

create a /lib/libperl.la
and symlink /lib/libperl.dll.a to
/lib/perl5/5.8.5/cygwin-thread-multi-64int/CORE/libperl.dll.a


Once again, mostly true, but entirely missing the point.

Whatever symlink games you play at *link-time* (i.e gcc, binutils), only one name can be hardcoded into the final binary, and that file must be a real file, not a symlink, because at *run-time* it is a core component of Windows which reads the data structures in the PE file, and loads and links the DLLs, without any influence from any part of Cygwin.

Sure. But who instantiates the loading of the DLL?
It's LoadLibrary(). (LoadLibraryExA() probably)
And in Cgywin it's dlopen(), which resolves the paths before LoadLibrary(). LoadLibrary gets the real, specialized dll.


So we can safely symlink even a dll. Just don't use the name of symlinked dll with a mingw32 version or MSVC version then.
mingw32 builds have to link against the specialized target dll.
"-lperl5_8_5" in the weird, underscored parlance.
But that's their problem then, not ours. And it will not work, because our dll loads cygwin1.dll.


I know that quite good, because I've written a number of FFI's
("Foreign Function Interfaces"), which do just that. At run-time.
One could even work around LoadLibrary(), GetProcAdress() and friends and load it manually, but that's not needed here.
We had to do that for AIX < 4.2 and for various lisps.
Jens-Uwe Mager also wrote some dlfcn.


BTW: LoadLibrary("C:\\cygwin\\bin\\cygperl-5.8.5.dll") will also work.
So one may use dots, and not only underscores. If you provide the full name with the ".dll" extension.
Same for the .def file hint.
Library "cygperl-5.8.5.dll" will work ok.
--
Reini Urban
http://xarch.tu-graz.ac.at/home/rurban/



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