symlink dll

[Reini Urban]

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/