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

[Eric Blake]

> Hi Eric,
> 
> * Eric Blake wrote on Wed, Oct 26, 2005 at 05:11:57PM CEST:
> > CVS head is currently broken on cygwin.  It looks like the patch
> > to rename lt_dlhandle_next to lt_dlhandle_iterate was incomplete.
> 
> Yep.  And we see me goofing up once more: loadlibrary.c:vm_open()
> really _has_ to iterate over _all_ modules.  One could argue this to be
> internal use, but we do rely on this now-undocumented detail of
> lt_dlhandle_iterate here.

Something I'm trying right now is 

Index: libltdl/ltdl.c
===================================================================
RCS file: /cvsroot/libtool/libtool/libltdl/ltdl.c,v
retrieving revision 1.236
diff -u -b -r1.236 ltdl.c
--- libltdl/ltdl.c      26 Oct 2005 10:26:48 -0000      1.236
+++ libltdl/ltdl.c      26 Oct 2005 20:12:55 -0000
@@ -2125,6 +2125,8 @@
 
   if (!handle)
     handle = (lt__handle *) handles;
+  else
+    handle = handle->next;
 
   /* advance while the interface check fails */
   while (handle && iterator->iface
Index: libltdl/loaders/loadlibrary.c
===================================================================
RCS file: /cvsroot/libtool/libtool/libltdl/loaders/loadlibrary.c,v
retrieving revision 1.9
diff -u -b -r1.9 loadlibrary.c
--- libltdl/loaders/loadlibrary.c       23 Sep 2005 07:58:42 -0000      1.9
+++ libltdl/loaders/loadlibrary.c       26 Oct 2005 20:12:55 -0000
@@ -160,8 +160,9 @@
      find one. */
   {
     lt__handle *        cur        = 0;
+    lt_dlinterface_id   all        = lt_dlinterface_register ("all", NULL);
 
-    while ((cur = (lt__handle *) lt_dlhandle_next ((lt_dlhandle) cur)))
+    while ((cur = (lt__handle *) lt_dlhandle_iterate (all, (lt_dlhandle) cur)))
       {
         if (!cur->module)
           {


Hmm, lt_dlinterface_register leads to a memory leak; so my patch
idea above is incomplete.  We also need something like:

lt_dlinterface_unregister (lt_dlinterface_id)
{
  lt__free ((lt__interface_id *) lt_dlinterface_id);
}

> 
> Now that I look at it, there's potential for more subtle breakage in
> loadlibrary.c, but this one independent of our recent changes:
> 
> |       /* Append a `.' to stop Windows from adding an
> |          implicit `.dll' extension. */
> |       searchname = MALLOC (char, 2+ LT_STRLEN (filename));
> |       if (searchname)
> |         sprintf (searchname, "%s.", filename);
> ...
> | #if defined(__CYGWIN__)
> |     {
> |       char wpath[MAX_PATH];
> |       cygwin_conv_to_full_win32_path (searchname, wpath);
> |       module = LoadLibrary (wpath);
> |     }
> | #else
> |     module = LoadLibrary (searchname);
> | #endif

Why is cygwin even trying to use LoadLibrary?  Cygwin comes
with dlopen(), after all.

> 
> Does `cygwin_conv_to_full_win32_path' DTRT the right thing on cygwin
> managed mounts?  (Where The Right Thing[tm] is here defined as: do what
> we expect it to :)

I hope so.  <runs off to write a quickie test program>

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

--
Eric Blake