I only use "sage -python" or "sage -ipython" with PyCUDA stuff, so that part's probably right. I'm running 64-bit Fedora and 64-bit CUDA (straight from NVIDIA, I had to fight a fair bit with this to work with Fedora 11's 4.4 gcc), and PyCUDA's tests work fine with Sage's Python. I would try to get PyCUDA working with Sage's Python than try to get Sage to use non-Sage Python but I wish you luck on your gamble.
On Mon, Mar 1, 2010 at 11:19 PM, Matthew Bromberg <mattc...@earthlink.net>wrote: > I actually got to the point where it would install using a similar > approach. I've been using the special shell environment for sage that > forces the correct python paths and so forth. Unfortunately my install > segfaults when I try to run the tests. My systems python will run the > pycuda tests without complaining. Unfortunately I haven't had a chance to > dig much further. > > My next trick was going to be to attempt to make sage use my system > python. I found a website that walks you through the procedure, but I've > been so busy I haven't had a chance to try it. > > Out of curiosity are you running a 64 bit or 32 bit version of linux? I'm > running a 64 bit archlinux. I'm wondering if my cuda libraries are > compatible with the sandboxed python. > > On 3/1/2010 2:09 PM, Ahmed Fasih wrote: > > Ignoring the oft-considered and oft-rejected suggestion that Sage > integrate with its host system, I take it that you couldn't get PyCUDA > 0.9.3 working. I just got it working with Sage, Fedora 11, etc. > > When installing Boost 1.4.2, I made sure to "./bootstrap.sh --help" > and see how to provide the correct Python path. My project-config.jam > had the following line: > > using python : 2.6 : /home/aldebrn/sage/local ; > > Then of course PyCUDA wouldn't build. Here's the command I had to run: > > $ sage -python configure.py --boost-inc-dir=/home/aldebrn/pool/include > --boost-lib-dir=$HOME/pool/lib --boost-python-libname=boost_python -- > boost-thread-libname=boost_thread --cuda-root=/usr/local/cuda > > Note that boost_python and boost_thread were from my boost/lib > directories. I also had to symlink libcuda.so from /usr/local/cuda/ > lib64 to /usr/local/cuda/lib. > > Then I ran into this utterly absurd setuptools junk. I'll take my > queue from Andreas' restraint and not complain bitterly like I want > to. Anyway, after going into my sage/local/lib/python2.6/site-packages > directory and > > $ rm setuptools* > > then going to my sage/local and deleting everything that > > $ find | grep easy_install > > revealed, I was able to build PyCUDA with "make install" and test it. > It does complain about something, but it works: > > $ sage -python test_driver.py > /home/aldebrn/sage/local/lib/python2.6/site-packages/pycuda-0.93-py2.6- > linux-x86_64.egg/pycuda/compiler.py:11: UserWarning: > call_capture_stdout is deprecated: use call_capture_output instead > return call_capture_stdout([nvcc, "--version"]) > ................ > ---------------------------------------------------------------------- > Ran 16 tests in 4.719s > > OK > > Hope this helps some hapless soul. > > On Feb 20, 8:52 pm, SevenThunders <mattc...@earthlink.net> > <mattc...@earthlink.net> wrote: > > > I posted this on the development list, but maybe I should have posted > here: > > I have an archlinux x86-64 desktop and I successfully installed > (compiled) sage. I'd like to add some additional functionality > however, but I've been stymied by a number of issues. First my top > issue is to get pycuda working with sage, which apparently others > have done. Unfortunately sage has an installation of setuptools which > doesn't work with pycuda, and is supposed to be somewhat deprecated as > of python 2.6.4. > > -------------- > I get an error of this type: > Does your error message look like this? > > "/usr/local/lib/python2.6/dist-packages/setuptools-0.6c9- > py2.6.egg/setuptools/command/build_ext.py", > line 85, in get_ext_filename > KeyError: '_something' > > You are using Python 2.6.3 with Setuptools. This will not work. > Uninstall setuptools, install > distribute.http://wiki.tiker.net/DistributeVsSetuptools#switching > --------------- > > Two other python libraries I could not install are PyQt4 and pygtk. > The latter runs up against an error: > -------------- > /usr/bin/ld: /opt/sage/sage/local/lib/../lib/ > libpython2.6.a(abstract.o): relocation R_X86_64_32 against > `.rodata.str1.8' can not be used when making a shared object; > recompile with -fPIC > /opt/sage/sage/local/lib/../lib/libpython2.6.a: could not read > symbols: Bad value > -------------- > > This prevents some other libraries from installing. > > I'm not sure why the sage python distribution is so persnickety. What > I'd like to know is how hard would it be to compile sage and configure > it to use Arch Linux's system python, rather than the sandboxed > python that comes with sage. This would make it much easier to > reliably use other python packages, though of course it doesn't > guarantee that sage would see a proven and tested environment, though > isn't version control and package dependencies supposed to mitigate > this issue? > > > > No virus found in this incoming message. > Checked by AVG - www.avg.com > Version: 9.0.733 / Virus Database: 271.1.1/2715 - Release Date: 02/28/10 > 14:34:00 > > > > -- To post to this group, send email to sage-support@googlegroups.com To unsubscribe from this group, send email to sage-support+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-support URL: http://www.sagemath.org
