ctypes - unloading implicitly loaded dlls
Here's what I'm struggling with (as best as I can understand it):
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 is that 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! "The procedure entry point some_func could not be located
# in the dynamic link library libC.dll.":
B = ctypes.cdll.LoadLibrary('/path2/libB.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?
Notes:
* the two sets of dlls are supplied by a vendor for working with its COTS
packages; I don't have any control over the dll names used or the code
therein.
* If I leave out the call to A.foo(), then I don't crash, but if I leave out
the FreeLibrary call as well then I do crash.
* I've tried manipulating the PATH before loading the dlls, to no effect.
* I've tried del'ing A and running gc.collect() before loading B.
--
http://mail.python.org/mailman/listinfo/python-list
Can multiprocessing.Process() use a different version of the interpreter?
I want to use the 64 bit version of python but run some code inside a spawned process that uses the 32 bit version. Is there an official way to do this, or can anybody make a recommendation about the cleanest way to do this? If someone has a better solution to the problem I describe below, I'd appreciate hearing that too. I'm using python 2.7, but could go to 3.x if that has better support for this. My program interacts with two different commercial libraries by using ctypes to execute functions inside their DLLs. One library only exists in a 32 bit version. The second library has both 64 and 32 bit versions. The code was initially developed for a 32 bit platform, but now I need to support a user on a 64 bit machine as well. I've learned that ctypes can only interact with libraries which match the version of python that is running --- 32 bit python can use 32 bit DLLs, 64 bit python can use 64 bit DLLs, so when I'm running on a 64 bit machine with one 64 bit library and the other at 32 bits, I can't use the 32 bit library. I believe that the solution is to have both win32 and x64 versions of python installed, and then execute the win32 code inside of a new process which uses the win32 version of Python. I'm already using multiprocessing to run that code inside a new process because the two libraries have conflicts and need to run in separate memory space. If I could just specify that I want the new process to use a different version of the interpreter I think I'd be all set, but I don't see a way of doing that. -- http://mail.python.org/mailman/listinfo/python-list
Re: Can multiprocessing.Process() use a different version of the interpreter?
On Oct 4, 1:34 pm, Robert Kern wrote: > My previous statement notwithstanding, there is a way to hack this. The > windows-specific implementation of the class multiprocessing.forking.Popen > uses > a global variable, _python_exe, to determine the executable to use. Instead, > you What I've been looking at since I first posted is that that _python.exe variable is built from sys.exec_prefix. So, I think that I can make it work by resetting sys.exec_prefix to the install dir of the 32 bit version before creating the new Process(). -- http://mail.python.org/mailman/listinfo/python-list
Re: Can multiprocessing.Process() use a different version of the interpreter?
On Oct 4, 1:41 pm, Scott Pigman wrote: > _python.exe variable is built from sys.exec_prefix. So, I think that sorry, _python_exe. -- http://mail.python.org/mailman/listinfo/python-list
Re: Can multiprocessing.Process() use a different version of the interpreter?
> > Personally, I think that subclassing is cleaner, but if you must monkeypatch, > then you should monkeypatch the multiprocessing.forking._python_exe variable, > not sys.exec_prefix. > > -- > Robert Kern thanks, good point. -- http://mail.python.org/mailman/listinfo/python-list
