questions from a new PythonNet user
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.ht... 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 $
participants (3)
-
Brian Lloyd
-
Hamilton Link
-
John Burnett