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
