I'm researching an appropriate (or at least straightforward stack) for ultimately getting skeleton information from a kinect, via a python api on an OSX platform. Most of the information I am finding is quite spread out and disconnected.
While it seems perfectly obvious that a windows-based stack would be microsoft's own pykinect on top of their kinect SDK, I can't seem to figure out what works well in an OSX environment.
Here is the info that I have compiled so far:
libfreenect is the obvious source for the low level drivers (this part is working just fine)
OpenNI offers the framework + NITE middleware to provide recognition. (not python)
PyOpenNI - python bindings for OpenNI with support for skeleton and other advanced features.
I have concluded that this is the most recommended stack to date. What I would like to achieve is simple skeleton data similar to what the windows SDK python wrapper gives you out of the box. Ultimately I will be using this in a PyQt-based app to draw the display, and then into Maya to apply the data.
My question is two parts, and I would accept an answer in either direction if it were the most appropriate...
Build issues for PyOpenNI
So far, I have been unable to successfully build PyOpenNI on either OSX Snow Leopard (10.6.8), or Lion (10.7.4). Both systems have updated xcode. I have noticed that the source files are hardcoded to expect python2.7, so on snow leopard I have had to make sure it was installed and the default version (also tried a virtualenv).
On Snow Leopard, I was seeing the cmake process find different libs, headers, bin for python, and ultimately the make produced an .so that crashed with 'mismatched interpreter'.
On Lion, I also got mismatched interpreter crashes. But after I installed python2.7 via homebrew, it generated a new error:
ImportError: dlopen(./openni.so, 2): Symbol not found: _environ
Referenced from: /usr/local/lib/libpython2.7.dylib
Expected in: dynamic lookup
Are there any specific steps to building this on OSX that I am missing, such as environment variables to ensure its pointing at the correct python2.7 libs? Does anyone have a successful build process for this platform?
Alternate question
Is this still the most recommended stack for OSX?
Follow up
I've accepted my own answer as a temporary working solution. If someone can provide a better one, I will gladly accept it!
Update
Part of this process isn't necessary after a patch I submitted (information here). Since then I have also written up a more detailed blog post about installing the entire stack on OSX: Getting Started With Xbox360 Kinect On OSX
After hacking around on this a bit, I have found a working fix (though it doesn't address the issue at the build level). There is an existing issue with cmake, where it does not properly detect other python frameworks besides the system framework (which causes the mismatch between the python binary and the libs).
I first reinstalled my python2.7 install via homebrew, adding the --framework flag
After building the module, I noticed via otool that it was still linking to my system python, and the system python on Lion is fat i386 and x86_64. I also noticed that the libboost (boost installed via homebrew) which was linked to openni.so was also linked against the system python instead of homebrew. So I used the following to relink them:
install_name_tool -change \
/System/Library/Frameworks/Python.framework/Versions/2.7/Python \
/usr/local/Cellar/python/2.7.3/Frameworks/Python.framework/Python \
openni.so
install_name_tool -change \
/System/Library/Frameworks/Python.framework/Versions/2.7/Python \
/usr/local/Cellar/python/2.7.3/Frameworks/Python.framework/Python \
/usr/local/Cellar/boost/1.49.0/lib/libboost_python-mt.dylib
After doing this, I was able to import openni without any errors.
Here is the summary of the workaround:
python2.7 as framework, x86_64 (not fat)
libboost linked to the proper 64bit python
export CPPFLAGS="-arch x86_64"
cmake and make steps like normal
relink openni.so to the 64bit python
Ideally, someone would post a better answer than this one showing how to fix this during the build phase with environment variables, and not have to do a relink fix at the end.
Related
I´ve got a new MacBook Pro with M1 chip and it seems as if not alle of the open source software is converted to arm64.
Nethertheless, I try to compile missing tools (like numpy) manuell from source, like in the good ole days. As I try to do it I have to install, deinstall a lot and one tool is "port" which is working except for one thing that it complains all the time about Libraries I don't use anymore (because some tools (like Eclipse) for example are not working with Python 3.10). Therefore I regressed to Python 3.9 but every time I want to install something with "port" (which it does), it complains about the "old" Python 3.10 libs. How could I get rid of this messages?
Warning: Error parsing file
/opt/local/Library/Frameworks/Python.framework/Versions/3.10/lib/python3.10/site-packages/lxml/html/diff.cpython-310-darwin.so: Error opening or reading file
I was in a sort of "Dead-Lock" because versions, Libraries and executables were not consistent with Python, Eclipse, Python pip packages etc, because some packages weren't ported to amd64 until now. For example numpy and I tried to compile it from source which was possible but still not working.
Then I stumbled over a hint in a different problematic were Rosetta was recommended for that specific problem. (I´ve never worked with Rosetta because most applications were running)
So I duplicated the "terminal" Application and configured one for Rosetta, started and installed Python 3.10 in it with all new packages and startet all executables from that terminal.
After some fiddling Eclipse startet with Python and the packages which my application needed, like numpy.
(And in addition to that, it seems as if it very much faster than before)
Background:
I'm writing a non-commercial application in Python, that uses wxPython, and depends on pyPortMidi and SciPy (both available on PyPi). I would like to share this with a small circle of Mac users - who live in different countries.
I work on Ubuntu, and don't have access to OSX systems for testing.
What I'm looking for:
A end-user friendly means of deploying my application, especially given the dependencies
What I've found so far:
Like Ubuntu, OSX comes with it's own Python bundled
This answer
suggests py2app. However, it's not clear from the
documentation
whether I can build an OSX app on an Ubuntu platform. Ditto with cx-Freeze.
Specific Questions:
Can I use py2app to build an OSX app on Ubuntu? And will it automagically include the above dependencies, or do I need to specify it somehow?
If not, can I write some sort of OSX script that will install the package dependies (using easy install, perhaps), painlessly on the end-user system? I haven't used distutils before, and I'm unfamiliar with OSX scripting, so any pointers would be appreciated!
Apologies for the noob questions, and thanks in advance.
You can use py2exe for Windows
Freeze on Linux and as you say py2app for Mac
py2app doesn't work on non-mac machines. As suggested by #victor-castillo-torres, have a look at Freeze, as also suggested in the linked mailing list.
Py2app only works on OSX systems, the code does not support building
bundles for other platforms than the one it is running on. That
is, py2app uses the currently running python installation to build a
depedency graph and copies the files mentioned in that graph to the
application bundle.
From the point of view of building script to install the dependencies
for your script OSX is just like any other Unix system, but with
different GUI libraries. A script that uses easy_install to install
dependencies could be made to work, although I don't know if all your
dependencies are easily available that way (in particular wxPython).
Short Description
Is it possible to install Python 2.7.1 64/32bit from python.org on top of an existing install (from python.org) of Python 2.7.1 32bit?
Background
I installed the 32bit version for wxPython(2.8) support which until now has given me zero issues. There are a few modules that I am now having difficultly installing (psycopg2 and mysql-python). The warning messages in homebrew constantly warn me about not having a 64bit version of Python on the path. These warnings only add to my list of wanting to use a 64 bit version.
At the time I selected the 32bit install, the GUI for a particular project was the main focus. Now the GUI has been come very simple and the database back-end support (using Django) is much more important. This being said, using the development version of wxPython 2.9 (which supports OS X and 64bit 2.7) has become acceptable.
For the non-mac users, to help explain why I had to use the 32bit version please see this Brief guide to using virtualenv in a wxpython project
System Information
Development System
OS: Mac OS X Snow Leopard (10.6.7)
Python: 2.7.1 with virutalenv / virutalenv-wrapper
Project Dependencies:
Note that MySQL could be PostgresSQL's psycopg2 if I can get the postgresql to install with homebrew
Django==1.2.5
MySQL-python==1.2.3
PIL==1.1.7
PyVISA==1.3
pyserial==2.5
virtualenv==1.5.1
virtualenvwrapper==2.6.3
wsgiref==0.1.2
wxPython==2.8.11.0
wxPython-common==2.8.11.0
Deployment System
OS: Windows XP / Windows 7
Python: Hopefully none (goal to use py2exe, or similar tool)
Current Thoughts
I fear that my goal cannot be accomplished based on the file paths alone. In Windows 7 the identifier (x86) is placed in the path showing that it is a 32bit program, but on OS X the path would be the same for 32bit or 64/32bit installs (/Library/Frameworks/Python.framework/Versions/2.7/).
Any thoughts or comments would be helpful!
Update 5-18-2011: 8:40 AM
I have confirmed that using the pre-compiled (.dmg) framework builds, installing the a 64 bit version does blow away the 32 bit install. This did negatively effect my virtual environments in that all of the things I have installed in the environments was based on the 32 bit install nearly every module threw an error of some sort.
I still have not achieved installing 32 bit and 64 bit on the same machine, however looking into homebrew with greater detail does look this could be possible. The trick would be to define your own formulas for each of the python builds (from source) and rename the install directory to something like 'Python27_32' and 'Python27_64'. I'll keep exploring this front as I have time.
EDIT 7-12-2011: 10:51 AM CST
Has anyone out there been able control how homebrew compile options? Specifically how to select to use a 64bit compiler or a 32 bit compiler? I will create a new SO question if this doesn't bring anything up.
Check out http://www.macports.org/ Which provides ports of various flavors of linux/unix tools that don't appear in the default MacInstallation and duplicates those that it needs otherwise. It installs everthing in /opt/local instead of stepping on the installed base. With some manipulation of PATH and LD_LIBRARY_PATH this might give you the options you need.
I would use something like virtualenv. This way you can have as many different installs of python as you wish.
EDIT: To use different versions of python use:
virtualenv -p python2.6
Reference
Another possible solution that was provided in an answer to one of my questions aimed at using a virtual environment in the Windows world was using Buildout. This approach looks like it would allow me create an environment with the 32bit installed and another one with the 64bit.
I have not tested this out yet, but wanted to pass it along to anyone else attempting this feat.
Cheers!
I am supporting an application with a hard dependency on python-devel 2.3.7. The application runs the python interpreter embedded, attempting to load libpython2.3.so - but since the local machine has libpython2.4.so under /usr/lib64, the application is failing.
I see that there are RPMs for python-devel (but not version 2.3.x). Another wrinkle is that I don't want to overwrite the existing python under /usr/lib (I don't have su anyway). What I want to do is place the somewhere in my home directory (i.e. /home/noahz/lib) and use PATH and LD_LIBRARY_PATH to point to the older version for this application.
What I'm trying to find out (but can't seem to craft the right google search for) is:
1) Where do I download python-devel-2.3 or libpython2.3.so.1.0 (if either available)
2a) If I can't download python-devel-2.3, how do I build libpython2.3.so from source (already downloaded Python-2.3.tgz and
2b) Is building libpython2.3.so.1.0 from source and pointing to it with LD_LIBRARY_PATH good enough, or am I going to run into other problems (other dependencies)
3) In general, am I approaching this problem the right way?
ADDITIONAL INFO:
I attempted to symlink (ln -s) to the later version. This caused the app to fail silently.
Distro is Red Hat Enterprise Linux 5 (RHEL5) - for x86_64
You can use the python RPM's linked to from the python home page ChristopheD mentioned.
You can extract the RPM's using cpio, as they are just specialized cpio archives.
Your method of extracting them to your home directory and setting LD_LIBRARY_PATH and PATH should work; I use this all the time for hand-built newer versions of projects I also have installed.
Don't focus on the -devel package though; you need the main package. You can unpack the -devel one as well, but the only thing you'll actually use from it is the libpython2.3.so symlink that points to the actual library, and you can just as well create this by hand.
Whether this is the right approach depends on what you are trying to do. If all you're trying to do is to get this one application to run for you personally, then this hack sounds fine.
If you wanted to actually distribute something to other people for running this application, and you have no way of fixing the actual application, you should consider building an rpm of the older python version that doesn't conflict with the system-installed one.
Can you use one of these rpm's?
What specific distro are you on?
http://www.python.org/download/releases/2.3.3/rpms/
http://rpm.pbone.net/index.php3/stat/4/idpl/3171326/com/python-devel-2.3-4.i586.rpm.html
I have a linux VPS that uses an older version of python (2.4.3). This version doesn't include the UUID module, but I need it for a project. My options are to upgrade to python2.6 or find a way to make uuid work with the older version. I am a complete linux newbie. I don't know how to upgrade python safely or how I could get the UUID modules working with the already installed version. What is a better option and how would I go about doing it?
The safest way to upgrading Python is to install it to a different location (away from the default system path).
To do this, download the source of python and do a
./configure --prefix=/opt
(Assuming you want to install it to /opt which is where most install non system dependant stuff to)
The reason why I say this is because some other system libraries may depend on the current version of python.
Another reason is that as you are doing your own custom development, it is much better to have control over what version of the libraries (or interpreters) you are using rather than have a operating system patch break something that was working before. A controlled upgrade is better than having the application break on you all of a sudden.
The UUID module exists as a separate package for Python 2.3 and up:
http://pypi.python.org/pypi/uuid/1.30
So you can either install that in your Python2.4, or install Python2.6. If your distro doesn't have it, then Python is quite simple to compile from source. Look through the requirements to make sure all the libraries you need/want are installed before compiling Python. That's it.
The best solution will be installing python2.6 in the choosen directory - It will you give you access to many great features and better memory handling (infamous python=2.4 memory leak problem).
I have got several pythons installed onto my two computers, I found that the best solution for are two directories:
$HOME/usr-32
$HOME/usr-64
respectively to using operating system (I share $HOME between 32 and 64 bit versions of Linux).
In each I have one directory for every application/program, for example:
ls ~/usr-64/python-2.6.2/
bin include lib share
It leads completetely to avoiding conflicts between version and gives great portability (you can use usb pendrives etc).
Python 2.6.2 in previously example has been installed with option:
./configure --prefix=$HOME/usr-64/python-2.6.2