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<[email protected]> 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 [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/sage-support
URL: http://www.sagemath.org