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 files. 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. Agreed. Cheers, -- Gary V. Vaughan (g...@gnu.org) _______________________________________________ http://lists.gnu.org/mailman/listinfo/libtool