Re: GNU Libtool 2.2.8 released (stable)

[Gary V. Vaughan]

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 (address@hidden)