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: Gary V. Vaughan
Subject: Re: GNU Libtool 2.2.8 released (stable)
Date: Tue, 8 Jun 2010 13:46:48 +0700

[[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, 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.
However, I don't see a test for this functionality, so it would be
nice to add one so that we have some assurance that it really does
work as expected, and some documentation that explains that it works
like this (I didn't check the docs, so maybe we already have that part).

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.  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.

Cheers,
-- 
Gary V. Vaughan (address@hidden)



reply via email to

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