Hi there, I've just started working with PythonNet and I have a few
questions about getting it built and running. Any help would be
appreciated, here is my current situation and questions. Sorry for the
long email but I figured details can only help you help me.
I would like to be able to download and build PythonNet from scratch on
Windows XP (32-bit) and on Ubuntu. If I have to build the .net
assemblies on XP for use in Ubuntu that's fine. On Ubuntu I have python
2.5.2, gcc 4.3.2, and mono 1.9.1. I have the python dev and mono dev
things installed as well, and my /etc/mono/config file is populated with
the extra bits from the pythonnet distribution. On Windows I have
Visual Studio Pro 2008 and python 2.5.2. On both platforms I have the
latest (r100) from svn, and on Ubuntu I also have the
pythonnet-2.0-alpha2 distribution.
On Ubuntu once I put the svn-retrieved setup.py I was able to rebuild
the pythonnet-2.0-alpha2 version of clr.so to be a 64-bit library; once
I had done this and set my GAC I was able to use "mono python.exe" (or
simply python.exe) and make a .net System.Drawing.Point object and get
its field values. Yay... except that starting python and doing "import
clr" made a heroic effort and then died. I'm using python2.5-UCS4
because in python, "len(u'\U00010800')" returns 1, is that correct?
Anyway, the error text is attached. I can't get very far building the
.net components checked out from svn because from what I can tell ilasm2
doesn't like some of the #define and #include and etc. in the code. Is
it possible to build everything with Mono or no?
On Windows I can build everything with no errors or warnings under VS
Pro. Pity mostly I want to use it under unix. I believe the assemblies
should work but there's this nasty little bit of .il that ends up 32- or
64-bit specific. So I need to know how to target 64-bit from a 32-bit
host and I'm not entirely sure what to configure in this case. I can
see how to configure for different python versions and UCS2/4, so that's
not a problem. If I can get guidance on targeting 32- or 64- by
inclusion of the proper .il file, I think I can build all the different
versions I need of the .net stuff and then I just need to be able to
build (or possibly just invoke) a working built version of clr.so over
on the unix side.
I suppose the first question is,
Why are there no apparent build instructions in the distribution?
It seems that there are more than half a dozen build configurations
(python 2.3, 4, 5, and 6, plus UCS2/4 distinctions for 5 and 6, plus
clr.so/.dll being built for a 32- or 64-bit system) and a couple of
possible build environments (VS or Mono+make), so breaking this all down
for first timers would really, really be appreciated. If I've just
missed them, I apologize, but the only thing I've been able to find so
far is
http://feihonghsu.blogspot.com/2008/02/installing-pythonnet-20-alpha-2-on.html
and
http://feihonghsu.blogspot.com/2008/02/pythonnet-20-for-net-sp1_15.html
which are _great_ but they are at an unaffiliated web site, are only
Visual Studio instructions, and don't cover targeting 32/64 bit. I
should also mention that if there really aren't official build
instructions I will happily write some up (cribbing somewhat from Mr.
Feihong Hsu if he agrees) as soon as I have a clear understanding of the
process and can do it successfully, and I'll stick that into svn if I
can or post it to the mailing list for a dev to add if I can't.
How actively maintained is PythonNet at the moment?
It looks like since the project was made to work patches have become
infrequent, which I will take to mean that things work reasonably well.
But this putative .net SP1 patch (
http://mail.python.org/pipermail/pythondotnet/2008-January/000771.html )
was not apparently folded into SVN, was there a reason for this?
The distribution at
http://sourceforge.net/project/showfiles.php?group_id=162464 is missing
setup.py, is this an oversight (I notice it is in the svn distribution)?
Finally, is there active development towards a 2.0 final, or has the
project hit a bit of a plateau with 2.0 alpha2?
Thank you very much for your time,
hamilton
$ python
Python 2.5.2 (r252:60911, Oct 5 2008, 19:29:17)
[GCC 4.3.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import clr
Stacktrace:
at (wrapper managed-to-native) Python.Runtime.Runtime.Py_Initialize ()
<0x00057>
at (wrapper managed-to-native) Python.Runtime.Runtime.Py_Initialize ()
<0xffffffff>
at Python.Runtime.Runtime.Initialize () <0x00070>
at Python.Runtime.PythonEngine.Initialize () <0x00019>
at (wrapper runtime-invoke) Python.Runtime.PythonEngine.runtime_invoke_void
(object,intptr,intptr,intptr) <0xffffffff>
Native stacktrace:
/usr/lib/libmono.so.0 [0x7f1442c5661d]
/usr/lib/libmono.so.0 [0x7f1442c76a1d]
/lib/libpthread.so.0 [0x7f14446ff0f0]
/lib/libc.so.6(cfree+0x43) [0x7f1443d6df53]
/usr/lib/libpython2.5.so(PyString_InternInPlace+0xbb) [0x7f14411cdf1b]
/usr/lib/libpython2.5.so(PyString_InternFromString+0x22)
[0x7f14411d05c2]
/usr/lib/libpython2.5.so(PyType_Ready+0xa5) [0x7f14411e29e5]
/usr/lib/libpython2.5.so(_Py_ReadyTypes+0x74) [0x7f14411c3b84]
/usr/lib/libpython2.5.so(Py_InitializeEx+0x6b) [0x7f144123598b]
[0x418e2a37]
Debug info from gdb:
(no debugging symbols found)
(no debugging symbols found)
[Thread debugging using libthread_db enabled]
[New Thread 0x7f1444b176e0 (LWP 13719)]
[New Thread 0x418c0950 (LWP 13721)]
[New Thread 0x418f5950 (LWP 13720)]
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
0x00007f1443dd1482 in select () from /lib/libc.so.6
3 Thread 0x418f5950 (LWP 13720) 0x00007f14446fe851 in nanosleep ()
from /lib/libpthread.so.0
2 Thread 0x418c0950 (LWP 13721) 0x00007f14446fb2d9 in
pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0
1 Thread 0x7f1444b176e0 (LWP 13719) 0x00007f1443dd1482 in select ()
from /lib/libc.so.6
Thread 3 (Thread 0x418f5950 (LWP 13720)):
#0 0x00007f14446fe851 in nanosleep () from /lib/libpthread.so.0
#1 0x00007f1442d21212 in ?? () from /usr/lib/libmono.so.0
#2 0x00007f14446f73ea in start_thread () from /lib/libpthread.so.0
#3 0x00007f1443dd8c6d in clone () from /lib/libc.so.6
#4 0x0000000000000000 in ?? ()
Thread 2 (Thread 0x418c0950 (LWP 13721)):
#0 0x00007f14446fb2d9 in pthread_cond_wait@@GLIBC_2.3.2 ()
from /lib/libpthread.so.0
#1 0x00007f1442d240a5 in ?? () from /usr/lib/libmono.so.0
#2 0x00007f1442d2635b in ?? () from /usr/lib/libmono.so.0
#3 0x00007f1442d374ae in ?? () from /usr/lib/libmono.so.0
#4 0x00007f1442cbd133 in ?? () from /usr/lib/libmono.so.0
#5 0x00007f1442cdac5b in ?? () from /usr/lib/libmono.so.0
#6 0x00007f1442d35873 in ?? () from /usr/lib/libmono.so.0
#7 0x00007f1442d51c92 in ?? () from /usr/lib/libmono.so.0
#8 0x00007f14446f73ea in start_thread () from /lib/libpthread.so.0
#9 0x00007f1443dd8c6d in clone () from /lib/libc.so.6
#10 0x0000000000000000 in ?? ()
Thread 1 (Thread 0x7f1444b176e0 (LWP 13719)):
#0 0x00007f1443dd1482 in select () from /lib/libc.so.6
#1 0x00007f14427985ac in g_spawn_sync () from /usr/lib/libglib-2.0.so.0
#2 0x00007f1442798988 in g_spawn_command_line_sync ()
from /usr/lib/libglib-2.0.so.0
#3 0x00007f1442c566c6 in ?? () from /usr/lib/libmono.so.0
#4 0x00007f1442c76a1d in ?? () from /usr/lib/libmono.so.0
#5 <signal handler called>
#6 0x00007f1443d6df53 in free () from /lib/libc.so.6
#7 0x00007f14411cdf1b in PyString_InternInPlace ()
from /usr/lib/libpython2.5.so
#8 0x00007f14411d05c2 in PyString_InternFromString ()
from /usr/lib/libpython2.5.so
#9 0x00007f14411e29e5 in PyType_Ready () from /usr/lib/libpython2.5.so
#10 0x00007f14411c3b84 in _Py_ReadyTypes () from /usr/lib/libpython2.5.so
#11 0x00007f144123598b in Py_InitializeEx () from /usr/lib/libpython2.5.so
#12 0x00000000418e2a37 in ?? ()
#13 0x00000000013a7e60 in ?? ()
#14 0x00000000013a8db8 in ?? ()
#15 0x0000000000000000 in ?? ()
#0 0x00007f1443dd1482 in select () from /lib/libc.so.6
=================================================================
Got a SIGSEGV while executing native code. This usually indicates
a fatal error in the mono runtime or one of the native libraries
used by your application.
=================================================================
Aborted
$
_________________________________________________
Python.NET mailing list - PythonDotNet@python.org
http://mail.python.org/mailman/listinfo/pythondotnet