Am 09.12.2010 02:44, schrieb Laszlo Sebo: > The array would normally be initialized by calling _PyInt_Init(void). Sooo... > just to test my theory, i exposed that function and called it explicitly from > Python.Runtime.Initialize() and low and behold, import clr now works just > fine! > > So i'll now go on a hunt, and make sure everything is initialized properly, > i'm > guessing some main init function isn't being called somewhere when using > python.net from an embedded python.
This happens when you use a "python" binary that isn't linked against libpython*.so. For example Debian and Ubuntu build a shared library but the python exe is statically linked against libpython.a. I hit the same bug when I coded the initial port to Mono about three years ago. Try "ldd $(which python2.6) | grep libpython". If it doesn't show the Python shared library then you have to create your own binary. A statically typed exe calls only _PyInt_Init() in its own data segment. "import clr" loads the shared library which doesn't anything with the exe. You end up with two interpreters in one program. This should be documented in the Python.NET sources somewhere. The sources should also contain an example or Makefile that creates a dynamically linked python binary for you. Python 2.5 support on Linux with UCS4 used to be stable and mature, since it was my major testing and deployment platform. But the current state of Python.NET on Linux is ... well ... not so good. ;) Christian _________________________________________________ Python.NET mailing list - PythonDotNet@python.org http://mail.python.org/mailman/listinfo/pythondotnet
