From: Martin C. <cos...@wa...> - 2006-11-28 08:51:33
|
Dethe Elza wrote: [] > When I import visual, I do get the following error, although it > appears to work OK: > > >>> from visual import * > /sw/lib/python2.5/site-packages/visual/array_backend.py:1: > RuntimeWarning: Python C API version mismatch for module cvisual: > This Python has API version 1013, module cvisual has version 1012. > import cvisual > > I assume that is the warning you were talking about? Yes. I think (not 100% sure though) that it detects some trace of the python2.3 that libboost_python was built with. The cvisual module now links to the static version of libboost_python. When it linked to the dynamic version, at the place of the above warning there was a crash. > Under the assumption that Python2.5 extensions were binary > compatible, as long as it was the same version, I naively tried > moving cvisualpython.so and visual/ to the site-packages directory of > my framework build of Python2.5, but no such luck: > > >>> from visual import * > Traceback (most recent call last): > File "<stdin>", line 1, in <module> > File "/Library/Frameworks/Python.framework/Versions/2.5/lib/ > python2.5/site-packages/visual/__init__.py", line 15, in <module> > import array_backend > File "/Library/Frameworks/Python.framework/Versions/2.5/lib/ > python2.5/site-packages/visual/array_backend.py", line 1, in <module> > import cvisual > ImportError: dlopen(/Library/Frameworks/Python.framework/Versions/2.5/ > lib/python2.5/site-packages/cvisualmodule.so, 2): Symbol not found: > _PyType_GenericAlloc > Referenced from: /Library/Frameworks/Python.framework/Versions/2.5/ > lib/python2.5/site-packages/cvisualmodule.so > Expected in: /Library/Frameworks/Python.framework/Versions/2.5/ > Resources/Python.app/Contents/MacOS/Python The cvisualmodule.so wants to load this symbol PyType_GenericAlloc from the python executable. It is defined in Fink's python2.5, but apparently not in the framework version of the python executable. There it is defined in the Python library. The module is compiled with the -bundle-loader linker flag which can have this side effect. [] >> So for now I am just waiting for reports on working/non-working >> visual-py25 (and visual-py24 for that matter) installations. > > Looks good here. Thanks. [] > I think you've nailed the crux of the matter. What is wanted is (in > order of importance): > > 1. Run under Aqua with no dependencies on X11 (and thus no need for > gtk libraries) > 2. Integrate with other tools that run under a framework build of > Python (so, for instance, VPython programs could be packaged with > py2app, could run in the same process as PyObjC programs, could > interact with PyGame, etc.) > > I think there is some resistance to Fink because of perhaps some > instability in earlier versions, but more importantly, because Fink > tends to bring along more Linuxisms and retain a dependency on X11 > rather than integrating with Aqua. At least, that has been my > impression, whether fairly or not. It may appear so, because Fink traditionally focused on porting software from linux/Unix (hence X11) to Mac OSX. But there is no technical or philosophical reason why Fink cannot package Aqua applications and application bundles. There are a couple (though still very few) of them in Fink now. -- Martin |