[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: GNU Libtool 2.2.8 released (stable)
From: |
Gary V. Vaughan |
Subject: |
Re: GNU Libtool 2.2.8 released (stable) |
Date: |
Tue, 8 Jun 2010 21:56:32 +0700 |
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)
- GNU Libtool 2.2.8 released (stable), Gary V. Vaughan, 2010/06/04
- Message not available
- Message not available
- Re: GNU Libtool 2.2.8 released (stable), Bob Friesenhahn, 2010/06/08
- Re: GNU Libtool 2.2.8 released (stable), Gary V. Vaughan, 2010/06/08
- Re: GNU Libtool 2.2.8 released (stable), Bob Friesenhahn, 2010/06/08
- Re: GNU Libtool 2.2.8 released (stable), Gary V. Vaughan, 2010/06/09
- Re: GNU Libtool 2.2.8 released (stable), Bob Friesenhahn, 2010/06/09
Message not available