ctypes - unloading implicitly loaded dlls
Nick Craig-Wood
nick at craig-wood.com
Mon Jul 28 06:35:27 EDT 2008
pigmartian <scottpig1 at comcast.net> wrote:
> I'm writing a program that uses functionality from two different sets of
> cdlls which reside in two different directories, call them 'libA.dll'
> and 'libB.dll'. Although I don't directly use it, both directories
> contain a dll with the same name, although they aren't in fact
> identical. Call them, "libC.dll". However, the c-functions I call from
> the clls I do use seem to implicitly use "libC.dll". The problem that
> occurs after I load one dll and call functions in it, when I try to load
> the second dll I get windows errors because the second dll tries to call
> a function in its version of libC.dll, but it finds the version meant
> for libB.dll, which doesn't contain that function.
>
> Oy, I hope some sample code makes it clearer:
>
> def demo():
>
> A = ctypes.cdll.LoadLibrary('/path1/libA.dll')
> A.foo() # implicitly uses '/path1/libC.dll'
>
> _ctypes.FreeLibrary(A._handle)
>
> # CRASH!
> B = ctypes.cdll.LoadLibrary('/path2/libB.dll')
> # "The procedure entry point some_func could not be located
> # in the dynamic link library libC.dll.":
>
> # libB.dll wants to use code from '/path2/libC.dll', but
> # instead it finds '/path1/libC.dll' already loaded
> # in memory, which doesn't
> # contain the function call it wants.
>
>
> Assuming my understanding of things is correct, then I believe what I
> need to do is to remove /path1/libC.dll from memory before I try loading
> libB.dll, but I haven't found any way of doing that. Can anyone offer
> my some suggestions? Or, am I S.O.L.?
You could try loading C explicitly with ctypes.LoadLibrary() before
loading A, then you'll have a handle to unload it before you load B.
I think I'd probably split the code into two or three processes
though. Perhaps use http://pypi.python.org/pypi/processing to
communicate between them. That should get you out of DLL Hell!
(Don't load any of the DLLs before you start the worker processes
off.)
--
Nick Craig-Wood <nick at craig-wood.com> -- http://www.craig-wood.com/nick
More information about the Python-list
mailing list