[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: GNU Libtool 2.2.8 released (stable)
From: |
Charles Wilson |
Subject: |
Re: GNU Libtool 2.2.8 released (stable) |
Date: |
Tue, 08 Jun 2010 08:11:30 -0400 |
User-agent: |
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.8.1.23) Gecko/20090812 Thunderbird/2.0.0.23 Mnenhy/0.7.6.666 |
On 6/8/2010 2:46 AM, Gary V. Vaughan wrote:
> [[Adding Libtool List]]
>
> 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.
Once Windows has done so, and THEN libltdl attempts to do a
LoadLibrary(libjpeg) -- when libjpeg has already been "privately"
loaded, unbeknownst to libltdl -- what happens?
> and if it gets a request for a handle to a
> library it loaded already, it can pull one out of it's internal data
> structures without having to call the underlying module loader again.
Except that in this proposal, its internal data structures wouldn't know
that libjpeg has already been loaded.
> More interesting still: I think things might blow up if the .la files
> have been removed on a platform that does automatic deplib loading for
> runtime linking, say lt_dlopening libpng.dll (which pulls in zlib
> through LoadLibrary without libltdl knowing about it), and then the
> application tries to lt_dlopen libz.dll.
Uhm, isn't this the same scenario I was outlining, with libtiff + libjpeg?
> It then depends on whether
> the underlying LoadLibrary implementation is smart enough to realise
> that it already has a copy of libz in memory and returns a handle to
> it without trying to reload another copy first... this would be an
> interesting test to have in the next release to see what feedback it
> brings.
Yes.
--
Chuck
- 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