[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: Wed, 9 Jun 2010 12:37:07 +0700

Hi Bob,

On 8 Jun 2010, at 23:19, Bob Friesenhahn wrote:
> On Tue, 8 Jun 2010, Gary V. Vaughan wrote:
>>> Obviously this is already working fine.  Windows LoadLibrary() is smart 
>>> enough to know what it has already loaded.  The unloading sequence is much 
>>> more interesting since something could be unloaded which is still being 
>>> used.
>> Looks like another interesting test case for 2.2.10 to me :)
>> Do you feel motivated to write it?  Or at least add a description to
>> the TODO file in the tests directory?
> This seems more like a test of the OS than it would be of libltdl.

And in one respect, both tests do apply to the OS (implicit loading followed by 
explicit reload, and also the unloading sequence you mentioned); but more 
importantly are also tests of whether libltdl is doing the right thing in the 
face of how the various OS level runtime linkers behave. 

> We already know that libltdl does not normally *have* to explicitly load all 
> of the dependencies in order for a program to run, but it is possible that 
> the .la files contain some knowledge of library locations that Windows does 
> not have.  Without the smarts added by the .la files, we become dependent on 
> Windows default DLL search algorithms, which could potentially find a 
> similarly named library in some other location.

I think the search algorithm is another issue again, albeit somewhat related, 
since libltdl also has to behave correctly in the face of whatever brain-damage 
might exist at the OS level.  Unfortunately only libltdl can try to enforce 
some kind of uniformity in this are between platforms with runtime loaded 
modules - when the OS looks up dlls to satisfy the startup process of an 
executable, it's going to do that with whatever half-cocked search algorithm 
the OS feels like in that release, irrespective of the contents of our .la 

M4 master, for example, has had to simply turn off all the libltdl/OS run-time 
loader path searching to maintain any cross platform sanity (it does this by 
managing it's own search path environment variable, making the searches itself 
and then always passing fully qualified paths to libltdl).  That sort of 
functionality seems like it should really be in libltdl, which is supposed to 
help with this kind of thing.

In actual fact, I'm totally burnt out on the remaining spaghetti code in 
libltdl, and any time that I would otherwise have wasted trying to untangle it, 
I'll be spending on a rewrite (but don't hold your breath, it's not a small 
job).  Which is why I'm trying to find the right solutions to some of the 
things that the current implementation might have tackled suboptimally.

>  For example, the Windows default search algorithm might require that the 
> DLLs be in the executable search PATH, but LoadLibrary() is able to load a 
> DLL via an explicit filesystem path (outside of the Windows search PATH) as 
> well so paths in the .la file do add value.


Gary V. Vaughan (address@hidden)        

reply via email to

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