http://pythonnet.sourceforge.net/readme.html says:
Note that if you are running under Mono on a *nix system, you will
need to have a compatible version of Python installed. You will also
need to create a symbolic link to the copy of libpython2.x.so (in your
existing Python installation) in the PythonNet directory. This is
needed to ensure that the mono interop dll loader will find it by
name. For example:
ln -s /usr/lib/libpython2.4.so ./python24.so
Which works fine, But the "official" way to do this is to use a Mono
feature called DllMap, which is documented here:
http://www.mono-project.com/Config_DllMap
In practice, this means you create a file named
python.runtime.dll.config, with content:
<configuration>
<dllmap dll="python24" target="libpython2.4.so.1" os="!windows"/>
</configuration>
--
Seo Sanghyeon
Paul Harter wrote:
> To use python.net with it is fine as long as the initial import of clr
> takes place early on in the main thread. Otherwise it doesn't work on
> multi-processor machines. I don't know why.
import clr should always be the first thing you do in an app. "import
clr" loads and initializes the Python.Runtime assembly. During the
initialization Python's __import__ hook is replaced with a custom hook
for the CLR import magic. You can get in all kinds of trouble if you
replace __import__ in a thread while another threads tries to import an
assembly. Our you can suffer from an import dead lock. It's a race
condition.
In an embedded .NET or C/C++ app you shouldn't use clr. It's better to
import the Python.Runtime assembly and call its PythonEngine::InitExt()
static method. The sample implementation in
https://pythonnet.svn.sourceforge.net/svnroot/pythonnet/trunk/pythonnet/src…
contains a working example and some helpful notes from me. I run into a
problem with threads, too.
Christian
