libtool
[Top][All Lists]
Advanced

[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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]