ctypes - unloading implicitly loaded dlls

Nick Craig-Wood nick at craig-wood.com
Mon Jul 28 12:35:27 CEST 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