New submission from erik flister:
normally, CDLL(find_library('c')) is fine. but when running embedded in a
context that uses a different runtime version, this will cause an error
(example:
http://stackoverflow.com/questions/30771380/how-use-ctypes-with-msvc-dll-from-within-matlab-
erik flister added the comment:
> it would be better for MATLAB to embed the manifest in their host executable
> if they're going to load the DLL directly.
can you help me understand? as far as i could tell, we need python to use the
msvcr*.dll that comes with matlab, not v/v.
it
erik flister added the comment:
thanks - i still don't understand tho. if python would have to be recompiled
to use a different crt, why wouldn't matlab? if a manifest could fix matlab,
why couldn't one fix python?
i ran into all this trying to get shapely to load in ma
erik flister added the comment:
am i reading this wrong, that you can put the manifest into the .dll?
https://msdn.microsoft.com/en-us/library/ms235560(v=vs.90).aspx
--
___
Python tracker
<http://bugs.python.org/issue24
erik flister added the comment:
if it can't go into your .dll, what are libraries like shapely supposed to do?
tell their users to do all this manifest stuff if they're running embedded?
--
___
Python tracker
<http://bugs.python.o
erik flister added the comment:
relevant:
http://stackoverflow.com/questions/30771380/how-use-ctypes-with-msvc-dll-from-within-matlab-on-windows/#comment49619037_30771380
--
___
Python tracker
<http://bugs.python.org/issue24
erik flister added the comment:
well i can confirm @eryksun's method works, so it's not a problem with how the
manifest is included in the dll. to me, the real issue is that
ctypes.cdll.msvcrt and find_library('c') aren't correct. the first returns
something
erik flister added the comment:
> About the only possible solution here would be to special case ctypes to
> detect msvcr90 as a parameter (later versions of the CRT don't need it) and
> also whether another activation context already exists. We could also
> document the ne
erik flister added the comment:
thanks a lot for the detailed info steve, very clearly stated!
> Yeah, geos_c.dll really should have exported its own free() function.
> find_library('c') is probably the wrong approach here - if geos_c.dll is
> being rebuilt with different C
