[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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

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

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):

Still old, but not ancient:

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)

[...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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]