Re: FYI: 277-gary-rename-remaining-troublesome-ltdl-apis.diff

[Charles Wilson]

Eric Blake wrote:
> > <returning from the conquest>
> > Not quite.  On a managed mount, cygwin_conv_to_full_win32_path
> > (searchname, wpath); correctly returns the munged underlying
> > Windows name, but earlier in the code, you appended a trailing
> > dot.  Since a managed mount munges the trailing dot, you are
> > now trying to load (for example) "c:\cygwin\managed\libfoo%2E",
> > rather than "c:\cygwin\managed\libfoo.", so the call to LoadLibrary
> > won't see a trailing dot and will thus append an implicit ".dll".
>
>
> On the other hand, I just had a thought.  If you were to wait to
> append the trailing dot until after you have converted to the Windows
> name, this idiom of using a trailing dot to supress implicit .dll should
> then work just fine for using LoadLibrary even inside cygwin managed
> mounts.

But this still doesn't address the issue of WHY loadlibrary.c code is 
specialized for cygwin.  Yes, it would be NICE if cygwin libltdl could 
be configured to use either dlopen OR loadlibrary OR maybe both with one 
as a fallback for the other.  But it's hardly necessary: dlopen is the 
"official" way to demand-load DLLs on cygwin...

As of the cygwin release of libtool-1.5.20, only dlopen() is used; 
earlier releases (1.5.6 etc) used both dlopen and LoadLibrary.  I had 
thought that those old versions used dlopen, and fell back to 
LoadLibrary on failure -- that was the intended effect of the patch 
discussed here and here
http://gcc.gnu.org/ml/java/2003-11/msg00070.html
http://lists.gnu.org/archive/html/libtool-patches/2003-11/msg00023.html

However, recently it became apparent that those old versions of libltdl 
-- at least as distributed via the official cygwin mirrors -- *may* 
actually call LoadLibrary first, and 'fall back' to dlopen.  I think 
this was due to a semantic change within libltdl, concerning the order 
in which the internal list of loaders was traversed.  But I'm just 
guessing, AND the discrepancy could have been due to ill-maintained 
cygwin-specific patches in my official releases, or the ill-advised fork 
of libltdl that the guile people did (and have since repented of).

Anyway, LoadLibrary-then-dlopen is clearly wrong for cygwin.

Meanwhile, the recent merge of cygwin-specific patches into the main 
libtool 1.5.x development led to the current cygwin behavior for 
libtool-1.5.x: ONLY dlopen() and no LoadLibrary.  Plus, having a third 
party look over some of the cygwin-specific private patches in our 
official release was a good thing and helped eliminate some of the cruft.

Anyway, this change seems to have cleared up some issues exposed by the 
earlier (1.5.6-cygwin-patched) behavior, and now the official cygwin 
builds of libltdl/libtool are much closer to the libtool 1.5.20 release.

Given this experience with the LoadLibrary/dlopen "combo", I will 
probably ensure that official cygwin builds of libltdl 2.x use only 
dlopen.c and don't even try to use loadlibrary.c.  Therefore, this 
current effort to fix the cygwin-build of loadlibrary.c is *probably* of 
little use, unless someone can convince me that, contrary to cgf's advice:

Very old thread (which also demonstrates GVV's sentimental attachment to 
LoadLibrary on cygwin):
http://sources.redhat.com/ml/cygwin/2000-09/msg00564.html

Still old, but not ancient:
http://www.cygwin.com/ml/cygwin/2003-11/msg00054.html

Newer thread (Note that guile-1.6 discussed in this thread used a FORK 
of libltdl!! which may provide an alternate explanation for the 
dlopen/LoadLibrary preference issue discussed above.  The guile people 
have corrected this insanity, and now use the system libltdl if 
available or a "real" libtoolize-produced subproject within their 1.7 
series)
http://sources.redhat.com/ml/cygwin-apps/2005-10/msg00076.html

[...unless someone can convince me that, contrary to cgf's advice,] 
libltdl on cygwin should prefer win-native LoadLibrary to 
cygwin-provided dlopen.

Especially as dlopen, IIRC, does some cygwin specific things that 
LoadLibrary knows nothing about.

--
Chuck