|
From: | Charles Wilson |
Subject: | Re: FYI: 277-gary-rename-remaining-troublesome-ltdl-apis.diff |
Date: | Wed, 26 Oct 2005 19:45:05 -0400 |
User-agent: | Mozilla Thunderbird 1.0.6 (Windows/20050716) |
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.htmlHowever, 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.htmlNewer 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
[Prev in Thread] | Current Thread | [Next in Thread] |