On 8 Jun 2010, at 19:11, Charles Wilson wrote: > On 6/8/2010 2:46 AM, Gary V. Vaughan wrote: >> On 8 Jun 2010, at 08:56, Charles Wilson wrote: >>> What happens if libltdl is >>> used to load (say) libtiff which has an automatic dependency on libjpeg? >>> The initial LoadLibrary from libltdl pulls in libtiff.dll AND >>> libjpeg.dll, but only libtiff.dll gets a registered handle in libltdl. >>> Suppose then the client app explicitly loads libjpeg.dll via libltdl -- >>> does that work ok? >> >> If it doesn't, then that's a bug. Libltdl is supposed to keep track >> of everything it loads, > > But the point here is that Bob is advocating that (in the first half of > the example above) *libltdl* does NOT explicitly load the libjpeg > dependency. However, the Windows *will* load it "behind the scenes" and > automatically, when libltdl does a LoadLibrary(libtiff) because libtiff > depends on libjpeg.
Oh sorry, I thought you were talking about a libltdl client getting an lt_dlhandle, rather than libltdl getting a LoadLibrary handle from the Win32 APIs. So, yes you were already discussing my second example. Anyway, the comments in libltdl/loaders/loadlibrary.c say: /* libltdl expects this function to fail if it is unable to physically load the library. Sadly, LoadLibrary will search the loaded libraries for a match and return one of them if the path search load fails. We check whether LoadLibrary is returning a handle to an already loaded module, and simulate failure if we find one. */ Which implies that LoadLibrary() is indeed smart enough to find and return a handle to the already-in-memory copy of libjpeg, although I'd still like to have a test that confirms it empirically for all our loaders. Cheers, -- Gary V. Vaughan (g...@gnu.org) _______________________________________________ http://lists.gnu.org/mailman/listinfo/libtool