About the dll search algorithm of dlopen (patch-r3)

Michael Haubenwallner michael.haubenwallner@ssi-schaefer.com
Tue Aug 30 15:57:00 GMT 2016

Hi Corinna,

On 08/30/2016 04:51 PM, Corinna Vinschen wrote:
> On Aug 29 18:50, Michael Haubenwallner wrote:
>> On 08/26/2016 01:49 PM, Corinna Vinschen wrote:
>>> On Aug 26 13:18, Corinna Vinschen wrote:
>>> Apart from these minor bits and pieces, I really like this new
>>> pathfinder class, btw.
>> Thank you! :)
>> While at it: Combining dlopen thoughts with the "forkables" background
>> around replacing dlls-in-use leads me to this thought for redundant
>> calls of dlopen:
>> As we've already agreed that GetModuleHandleEx might make sense,
> Erm... where exactly did we do that?  I recall I mentioned using
> LoadLibraryEx with LOAD_LIBRARY_SEARCH_USER_DIRS and the AddDllDirectory
> functions, but I don't think we talked about GetModuleHandleEx.

Indeed not for dlopen calls including a path - but for without a path:

> The question is if it really makes sense to add calls to
> GetModuleHandleEx.  Apart from slowing down the dlopen call, it seems
> unnecessary.  Assuming you call LoadLibrary with the same paths and same
> extensions in the same order, wouldn't a second call to dlopen have the
> exact same result (loading the same file)?

Sure - as long as an already loaded dll is not replaced by an updated one.
Before I'll gonna try: Do you know by chance what LoadLibrary does here?

Artifical corner case LoadLibrary will never handle:
* 1st dlopen("libN.so") loads "libN.dll"
* same program installs newer package N, now providing "cygN.dll"
* 2nd dlopen("libN.so") loads "cygX.dll": expected is old "libN.dll" handle
This is true for both dlopen("libN.so") and dlopen("/path/lib/libN.so").

However, for perfomance reasons I can imagine some shared flag for both
dlopen and fork (others?): "support updating running binaries (NTFS only)",
to avoid the extra GetModuleHandleEx calls in dlopen by default.


More information about the Cygwin-developers mailing list