[Top][All Lists]

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

cygwin dlopening backends (was: FYI: 277-gary-rename-remaining-troubleso

From: Ralf Wildenhues
Subject: cygwin dlopening backends (was: FYI: 277-gary-rename-remaining-troublesome-ltdl-apis.diff)
Date: Fri, 28 Oct 2005 10:59:21 +0200
User-agent: Mutt/1.5.11

Hi Charles, Eric,

* Charles Wilson wrote on Thu, Oct 27, 2005 at 01:45:05AM CEST:
> 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...


First, let me thank you for your insightful and very nicely written
mail; the thread pointers are very helpful -- it took a while to read
through them all.

There are several separate issues here:

1) lt_dlhandle_iterate breakage of loadlibrary.c
2) needed dlinterface_free (or maybe _unregister?)
   including documentation
3) cygwin managed mount fix of loadlibrary.c
   or remove the cygwin-specific code of loadlibrary.c
4) use either
    - only dlopen, or
    - first dlopen, then LoadLibrary
   on cygwin, or
    - make the choice configurable

I want (3) fixed or the cygwin-specific code removed, depending on (4).
Rationale: I dislike broken code, even when unused; if it's just because
others might copy and paste from it (which has happened before!).

My vote would be to allow users the choice by making it configurable,
with the default being to use `dlopen' _only_, for the reasons given in
the cited threads.  I definitely want GNU libtool 2.0 to be identical to
cygwin libtool; after all, that was the point of going through the 1.5
differences.  Also, I want the guile and libjava users to be able to use
an unmodified libltdl.

Patches in addition to the ones provided by Eric, for any of these
issues, are welcome.  It may take a few days until I have time to work
on this or test on a w32 box.

[ Note to self: when going back to Peter Ekberg's msvc patches: if they
work with cygwin (which I haven't tested so far; only msys), be sure to
check that LoadLibrary will be enabled in this case. ]


reply via email to

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