pycuda make error
by Dwight Bell
I'm trying to install pycuda on Max OS X 10.6.1 and got the following
error:
dbmacpro:make -j 4
ctags -R src || true
ctags: illegal option -- R
usage: ctags [-BFadtuwvx] [-f tagsfile] file ...
/Library/Frameworks/Python.framework/Versions/2.6/Resources/Python.app/
Contents/MacOS/Python setup.py build
/Users/dbelll/src/pycuda-0.93/ez_setup.py:93: UserWarning: Module
pkg_resources was already imported from /Users/dbelll/src/pycuda-0.93/
pkg_resources.pyc, but /Library/Frameworks/Python.framework/Versions/
2.6/lib/python2.6/site-packages/distribute-0.6.8-py2.6.egg is being
added to sys.path
import pkg_resources
/Users/dbelll/src/pycuda-0.93/ez_setup.py:93: UserWarning: Module site
was already imported from /Library/Frameworks/Python.framework/
Versions/2.6/lib/python2.6/site.pyc, but /Library/Frameworks/
Python.framework/Versions/2.6/lib/python2.6/site-packages/
distribute-0.6.8-py2.6.egg is being added to sys.path
import pkg_resources
/Users/dbelll/local/include/boost-1_39 /boost/ python .hpp
/Users/dbelll/local/lib / lib boost_python-xgcc40-mt .so
/Users/dbelll/local/lib / lib boost_python-xgcc40-mt .dylib
/Users/dbelll/local/lib / lib boost_thread-xgcc40-mt .so
/Users/dbelll/local/lib / lib boost_thread-xgcc40-mt .dylib
/usr/local/cuda /bin/ nvcc
/usr/local/cuda/include / cuda .h
/usr/local/cuda/lib / lib cuda .so
/usr/local/cuda/lib / lib cuda .dylib
running build
running build_py
running build_ext
--------------------------------------------------------------------------
Sorry, your build failed. Try rerunning configure with different
options.
--------------------------------------------------------------------------
Traceback (most recent call last):
File "setup.py", line 325, in <module>
main()
File "setup.py", line 317, in main
("include/cuda", glob.glob("src/cuda/*.hpp"))
File "/Users/dbelll/src/pycuda-0.93/aksetup_helper.py", line 12, in
setup
setup(*args, **kwargs)
File "/Library/Frameworks/Python.framework/Versions/2.6/lib/
python2.6/distutils/core.py", line 152, in setup
dist.run_commands()
File "/Library/Frameworks/Python.framework/Versions/2.6/lib/
python2.6/distutils/dist.py", line 975, in run_commands
self.run_command(cmd)
File "/Library/Frameworks/Python.framework/Versions/2.6/lib/
python2.6/distutils/dist.py", line 995, in run_command
cmd_obj.run()
File "/Library/Frameworks/Python.framework/Versions/2.6/lib/
python2.6/distutils/command/build.py", line 134, in run
self.run_command(cmd_name)
File "/Library/Frameworks/Python.framework/Versions/2.6/lib/
python2.6/distutils/cmd.py", line 333, in run_command
self.distribution.run_command(command)
File "/Library/Frameworks/Python.framework/Versions/2.6/lib/
python2.6/distutils/dist.py", line 995, in run_command
cmd_obj.run()
File "/Users/dbelll/src/pycuda-0.93/setuptools/command/
build_ext.py", line 46, in run
_build_ext.run(self)
File "/Library/Frameworks/Python.framework/Versions/2.6/lib/
python2.6/distutils/command/build_ext.py", line 340, in run
self.build_extensions()
File "/Library/Frameworks/Python.framework/Versions/2.6/lib/
python2.6/distutils/command/build_ext.py", line 449, in build_extensions
self.build_extension(ext)
File "/Users/dbelll/src/pycuda-0.93/setuptools/command/
build_ext.py", line 175, in build_extension
_build_ext.build_extension(self,ext)
File "/Library/Frameworks/Python.framework/Versions/2.6/lib/
python2.6/distutils/command/build_ext.py", line 460, in build_extension
ext_path = self.get_ext_fullpath(ext.name)
File "/Library/Frameworks/Python.framework/Versions/2.6/lib/
python2.6/distutils/command/build_ext.py", line 637, in get_ext_fullpath
filename = self.get_ext_filename(ext_name)
File "/Users/dbelll/src/pycuda-0.93/setuptools/command/
build_ext.py", line 85, in get_ext_filename
ext = self.ext_map[fullname]
KeyError: '_driver'
make: *** [all] Error 1
dbmacpro:
My siteconf.py is:
BOOST_INC_DIR = ['/Users/dbelll/local/include/boost-1_39']
BOOST_LIB_DIR = ['/Users/dbelll/local/lib']
BOOST_COMPILER = 'gcc43'
BOOST_PYTHON_LIBNAME = ['boost_python-xgcc40-mt']
BOOST_THREAD_LIBNAME = ['boost_thread-xgcc40-mt']
CUDA_TRACE = False
CUDA_ROOT = '/usr/local/cuda'
CUDA_ENABLE_GL = False
CUDADRV_LIB_DIR = []
CUDADRV_LIBNAME = ['cuda']
CXXFLAGS = []
LDFLAGS = []
Has anyone run into this same problem? Any suggestions on what to try
would be appreciated.
... Dwight Bell
9 years, 9 months
bad argument to internal function
by Ken Seehart
Something like this came up for someone else in May:
http://www.mail-archive.com/pycuda@tiker.net/msg00361.html
*SystemError: ../Objects/longobject.c:336: bad argument to internal
function*
File
"/home/ken/projects/gpuserver/secure/static/snippets/yarng/yarng.py",
line 453, in <module>
test('e')
File
"/home/ken/projects/gpuserver/secure/static/snippets/yarng/yarng.py",
line 438, in test
f(rng, v)
File
"/home/ken/projects/gpuserver/secure/static/snippets/yarng/yarng.py",
line 293, in test_ent
self.randomize(v)
File
"/home/ken/projects/gpuserver/secure/static/snippets/yarng/yarng.py",
line 224, in randomize
self.cu_randomize(self.cu_v, self.n, block=(self.N_THREADS_PER_BLOCK,
1, 1), grid=(self.N_BLOCKS, 1))
File
"/usr/local/lib/python2.6/dist-packages/pycuda-0.91.1-py2.6-linux-i686.egg/pycuda/driver.py",
line 108, in function_call
handlers = func.param_set(*args)
File
"/usr/local/lib/python2.6/dist-packages/pycuda-0.91.1-py2.6-linux-i686.egg/pycuda/driver.py",
line 85, in function_param_set
buf = struct.pack(format, *arg_data)
I fixed it by hacking *_add_functionality* in *driver.py*.
The problem seems to be that the *struct* module doesn't know how to
pack a *numpy.int32* as *'L'*. Perhaps this is due to a change in
*numpy,* or some kind of change in *python 2.6*.
My solution was to simply convert the argument to *long* when it is
appended to *arg_data*, since the important type information is
extracted in the following line (format += arg.dtype.char).
This fixed my problem. Thought you'd like to know.
I'm not how to submit a patch (didn't find anything on
http://wiki.tiker.net/PyCuda).
*def function_param_set(func, *args):*
try:
import numpy
except ImportError:
numpy = None
handlers = []
arg_data = []
format = ""
for i, arg in enumerate(args):
if numpy is not None and isinstance(arg, numpy.number):
* arg_data.append(long(arg)) # convert to long so that
struct.pack will be able to format the data
* format += arg.dtype.char
elif isinstance(arg, (DeviceAllocation, PooledDeviceAllocation)):
arg_data.append(int(arg))
format += "P"
elif isinstance(arg, ArgumentHandler):
handlers.append(arg)
arg_data.append(int(arg.get_device_alloc()))
format += "P"
elif isinstance(arg, buffer):
arg_data.append(arg)
format += "s"
else:
try:
gpudata = arg.gpudata
except AttributeError:
raise TypeError("invalid type on parameter #%d
(0-based)" % i)
else:
# for gpuarrays
arg_data.append(int(gpudata))
format += "P"
import struct
buf = struct.pack(format, *arg_data)
func.param_setv(0, buf)
func.param_set_size(len(buf))
return handlers
9 years, 11 months
CUDA 3.0 & 64-bit host code
by Bryan Catanzaro
Hi All -
I built 64-bit versions of Boost and PyCUDA on Mac OS X Snow Leopard, as well as the 64-bit Python interpreter supplied by Apple, as well as the CUDA 3.0 beta. Everything built fine, but when I ran pycuda.autoinit, I got an interesting CUDA error, which PyCUDA reported as "pointer is 64-bit".
I'm wondering - is it impossible to use a 64-bit host program with a 32-bit GPU program under CUDA 3.0?
- bryan
9 years, 11 months
Alright, now what... :)
by William King
Ok, I'm testing pycuda now. I think I'll want to use pyopencl but until
I test that I'll use this.
So, it is working now... How would I get an md5 sum to get run? would
that be put into the kernel? Then the kernel would be run per 'thread' ?
Also, on a Nvidia GeForce 9500 GT, how many threads can be run at one
time? http://www.nvidia.com/object/product_geforce_9500gt_us.html
It is 'compute Capability' 1.1, so it has 32 multiprocessors so isn't
it 32*768=24,576 threads?
Can pycuda automatically max out all the cards on the machine? Or how
would I tell it to use both cards?
Also, here is the devices I'm using:
root@quentusrex-desktop:~/NVIDIA_GPU_Computing_SDK/C/bin/linux/release#
./deviceQuery
CUDA Device Query (Runtime API) version (CUDART static linking)
There are 2 devices supporting CUDA
Device 0: "GeForce 9500 GT"
CUDA Driver Version: 2.30
CUDA Runtime Version: 2.30
CUDA Capability Major revision number: 1
CUDA Capability Minor revision number: 1
Total amount of global memory: 1073020928 bytes
Number of multiprocessors: 4
Number of cores: 32
Total amount of constant memory: 65536 bytes
Total amount of shared memory per block: 16384 bytes
Total number of registers available per block: 8192
Warp size: 32
Maximum number of threads per block: 512
Maximum sizes of each dimension of a block: 512 x 512 x 64
Maximum sizes of each dimension of a grid: 65535 x 65535 x 1
Maximum memory pitch: 262144 bytes
Texture alignment: 256 bytes
Clock rate: 1.38 GHz
Concurrent copy and execution: Yes
Run time limit on kernels: Yes
Integrated: No
Support host page-locked memory mapping: No
Compute mode: Default (multiple host
threads can use this device simultaneously)
Device 1: "GeForce 9500 GT"
CUDA Driver Version: 2.30
CUDA Runtime Version: 2.30
CUDA Capability Major revision number: 1
CUDA Capability Minor revision number: 1
Total amount of global memory: 1073479680 bytes
Number of multiprocessors: 4
Number of cores: 32
Total amount of constant memory: 65536 bytes
Total amount of shared memory per block: 16384 bytes
Total number of registers available per block: 8192
Warp size: 32
Maximum number of threads per block: 512
Maximum sizes of each dimension of a block: 512 x 512 x 64
Maximum sizes of each dimension of a grid: 65535 x 65535 x 1
Maximum memory pitch: 262144 bytes
Texture alignment: 256 bytes
Clock rate: 1.38 GHz
Concurrent copy and execution: Yes
Run time limit on kernels: Yes
Integrated: No
Support host page-locked memory mapping: No
Compute mode: Default (multiple host
threads can use this device simultaneously)
Test PASSED
Press ENTER to exit...
9 years, 11 months
Re Re: Build Problems on SuSE 11.0, now Pytools not found
by Wolfgang Rosner
Hello, Andreas,
things are getting weared ^2
Am Sonntag, 22. November 2009 20:00:08 schrieb pycuda-request(a)tiker.net:
> > standard on SuSE is
> > /usr/lib64/python2.5/site-packages/
> >
> > but the egg-laying machine seems to put stuff to
> > /usr/local/lib64/python2.5/site-packages
> > instead
> > (maybe I could have reconfigured this, anyway)
>
> Weird. Curious about the reasoning behind this.
>
> > However, gl_interop.py did not run until I did
> > export PYTHONPATH=/usr/local/lib64/python2.5/site-packages/
> > (was PYTHONPATH="" before)
> >
> > maybe this is since there is still the old python-opengl-2.0.1.09-224.1
> > /usr/lib64/python2.5/site-packages/OpenGL/GL/ARB/
> > ...with-no-vertex-buffer-in-there in the way which is caught before.
> >
> > But to figure it out I'm definitely lacking sufficient python experience.
>
> There is an easy trick to find out what file path actually gets imported:
> >>> import pytools
> >>> pytools.__file__
>
> '/home/andreas/research/software/pytools/pytools/__init__.py'
tried it on two different consoles - one with empty $PYTHONPATH and one set as
above.
=== case 1 ==============================================
:~> echo $PYTHONPATH
:~> python
Python 2.5.2 (r252:60911, Jun 7 2008, 00:38:48)
[GCC 4.3.1 20080507 (prerelease) [gcc-4_3-branch revision 135036]] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import pytools
>>> pytools.__file__
'/usr/local/lib64/python2.5/site-packages/pytools-9-py2.5.egg/pytools/__init__.pyc'
>>> <ctrl>D
:~/ cd test/cuda/pycuda/pycuda/examples
:~/test/cuda/pycuda/pycuda/examples> python gl_interop.py
Traceback (most recent call last):
File "gl_interop.py", line 8, in <module>
from OpenGL.GL.ARB.vertex_buffer_object import *
ImportError: No module named vertex_buffer_object
=== case 2 ==============================================
:~/test/cuda/pycuda/pycuda> echo $PYTHONPATH
/usr/local/lib64/python2.5/site-packages/
:~/test/cuda/pycuda/pycuda> python
Python 2.5.2 (r252:60911, Jun 7 2008, 00:38:48)
[GCC 4.3.1 20080507 (prerelease) [gcc-4_3-branch revision 135036]] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import pytools
>>> pytools.__file__
'/usr/local/lib64/python2.5/site-packages/pytools-9-py2.5.egg/pytools/__init__.pyc'
>>> <ctrl>D
...
runnign gl_interop.py works...
=================================================
so, although the $PYTHONPATH environment variable solved my python-opengl
problem, there seems to be another place where the path info is kept / set.
Either in some global way? but then gl_interop.py should run in case 1, too
And I would consider it as bad implementation, having side effects of
environment variables between different consoles.
Think python itself ist quite mature, isn't it?
maybe >>> import pytools already changes the path.
Isn't there any python builtin way to show the module search path?
and how are all the SuSE-configured modules in
/usr/lib64/python2.5/site-packages/
found?
but something seems already screwed on my python:
looking for an answer for above question pops up an empty tk window and throws
an error ($PYTHONPATH=/usr/local/lib64/python2.5/site-packages/)
===== case 2 ======================
help> modules environment
Here is a list of matching modules. Enter any module name to get more help.
No handlers could be found for logger "OpenGL.Tk"
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/usr/lib64/python2.5/site.py", line 346, in __call__
return pydoc.help(*args, **kwds)
File "/usr/lib64/python2.5/pydoc.py", line 1644, in __call__
self.interact()
File "/usr/lib64/python2.5/pydoc.py", line 1662, in interact
self.help(request)
File "/usr/lib64/python2.5/pydoc.py", line 1680, in help
self.listmodules(split(request)[1])
File "/usr/lib64/python2.5/pydoc.py", line 1785, in listmodules
apropos(key)
File "/usr/lib64/python2.5/pydoc.py", line 1883, in apropos
ModuleScanner().run(callback, key)
File "/usr/lib64/python2.5/pydoc.py", line 1848, in run
for importer, modname, ispkg in pkgutil.walk_packages():
File "/usr/lib64/python2.5/pkgutil.py", line 125, in walk_packages
for item in walk_packages(path, name+'.', onerror):
File "/usr/lib64/python2.5/pkgutil.py", line 110, in walk_packages
__import__(name)
File "/usr/local/lib64/python2.5/site-packages/OpenGL/Tk/__init__.py", line
114, in <module>
_default_root.tk.call('package', 'require', 'Togl')
_tkinter.TclError: can't find package Togl
>>>
======= case 1 ====================
help> modules environment
Here is a list of matching modules. Enter any module name to get more help.
Speicherzugriffsfehler
:~/test/cuda/pycuda/pycuda/examples> echo $PYTHONPATH
:~/test/cuda/pycuda/pycuda/examples>
=======case 3=====================
help> module environment
no Python documentation found for 'module environment'
.....
:~/test/cuda/pycuda/pycuda/examples> echo $PYTHONPATH
/usr/lib64/python2.5/site-packages/,/usr/local/lib64/python2.5/site-packages/
==============================================
Obviously, only by manually restoring the supposed correct (depends?) search
sequence (core system first) in $PYTHONPATH restores a working python help
system.
So something's going on below the hood.
Would blame one of the packages I've installed in the course of testing
pycuda.
looking for potential suspects:
:~> ls -1 /usr/local/lib64/python2.5/site-packages/
easy-install.pth
matplotlib
matplotlib-0.99.1.1-py2.5.egg-info
mpl_toolkits
OpenGL
pycuda
pycuda-0.93.1rc2-py2.5.egg-info
pylab.py
pylab.pyc
PyOpenGL-3.0.1b1-py2.5.egg-info
pytools-9-py2.5.egg
setuptools-0.6c9-py2.5.egg
setuptools.pth
wx-2.8-gtk2-unicode
wxaddons
wxaddons-2.8.8.1-py2.5.egg-info
wx.pth
wxPython_common-2.8.8.1-py2.5.egg-info
wxversion.py
wxversion.pyc
===================================================
without real knowledge, I would start to blame the OpenGL and wx-stuff first.
Hope I have no crucial app on my box that relys on python.
hang on .... qgis ... loading python .... looks ok. :-)
So keep playing until I screw my daily work...
yours
Wolfgang
9 years, 11 months
Re: [PyCUDA] Install issue with Ubuntu 9.10
by Andreas Klöckner
On Sonntag 22 November 2009, you wrote:
> Now this error:
>
> python test_driver.py
> Traceback (most recent call last):
> File "test_driver.py", line 481, in <module>
> from py.test.cmdline import main
> ImportError: No module named cmdline
Again, py.test should have been installed automatically for you.
easy_install -U py
should do that for you. (Also see http://is.gd/4VBoW)
Andreas
PS: Please keep your replies on-list.
9 years, 12 months
Install issue with Ubuntu 9.10
by William King
Finally get all the way to the end. Then get this:
root@quentusrex-desktop:~/pycuda/pycuda/test# python test_driver.py
Traceback (most recent call last):
File "test_driver.py", line 475, in <module>
import pycuda.autoinit
File "/usr/local/lib/python2.6/dist-packages/pycuda/autoinit.py", line
6, in <module>
from pycuda.tools import make_default_context
File "/usr/local/lib/python2.6/dist-packages/pycuda/tools.py", line
31, in <module>
from pytools import memoize, decorator
ImportError: No module named pytools
root@quentusrex-desktop:~/pycuda/pycuda/test# cd ../../pytools-9
root@quentusrex-desktop:~/pycuda/pytools-9# python ez_setup.py -U setuptools
Searching for setuptools
Reading http://pypi.python.org/simple/setuptools/
Best match: setuptools 0.6c11
Downloading
http://pypi.python.org/packages/2.6/s/setuptools/setuptools-0.6c11-py2.6....
Processing setuptools-0.6c11-py2.6.egg
Moving setuptools-0.6c11-py2.6.egg to /usr/local/lib/python2.6/dist-packages
Adding setuptools 0.6c11 to easy-install.pth file
Installing easy_install script to /usr/local/bin
Installing easy_install-2.6 script to /usr/local/bin
Installed /usr/local/lib/python2.6/dist-packages/setuptools-0.6c11-py2.6.egg
Processing dependencies for setuptools
Finished processing dependencies for setuptools
root@quentusrex-desktop:~/pycuda/pytools-9# cd ../pycuda/test/
root@quentusrex-desktop:~/pycuda/pycuda/test# ls
test_driver.py test_gpuarray.py test_math.py undistributed
root@quentusrex-desktop:~/pycuda/pycuda/test# python test_driver.py
Traceback (most recent call last):
File "test_driver.py", line 475, in <module>
import pycuda.autoinit
File "/usr/local/lib/python2.6/dist-packages/pycuda/autoinit.py", line
6, in <module>
from pycuda.tools import make_default_context
File "/usr/local/lib/python2.6/dist-packages/pycuda/tools.py", line
31, in <module>
from pytools import memoize, decorator
ImportError: No module named pytools
9 years, 12 months
Re: [PyCUDA] Build Problems on SuSE 11.0, now Pytools not found
by Wolfgang Rosner
Hello, Andreas,
Am Samstag, 21. November 2009 20:00:10 schrieb pycuda-request(a)tiker.net:
> Message: 3
> Date: Sat, 21 Nov 2009 13:39:13 -0500
> From: Andreas Kl?ckner <lists(a)informa.tiker.net>
> Subject: Re: [PyCUDA] Build Problems on SuSE 11.0, x86_64 - cannot
> find -llibboost_python-mt
> To: pycuda(a)tiker.net
> Message-ID: <200911211339.19819.lists(a)informa.tiker.net>
> Content-Type: text/plain; charset="iso-8859-1"
>
> On Samstag 21 November 2009, Wolfgang Rosner wrote:
> > OK, for me it works now, but peomple might be even more (and earlier)
> > happy if the pytools issue had been mentioned in the setup wiki.
>
> Pytools should be installed automatically along with 'python setup.py
> install'. If it didn't: do you have any idea why?
not sure.
could it be that I ran "make install"
instead of "python setup.py install" ?
(sorry, I'm just getting used to Python, preferred perl in earlier live)
first I thought it was due to the different python path structures.
standard on SuSE is
/usr/lib64/python2.5/site-packages/
but the egg-laying machine seems to put stuff to
/usr/local/lib64/python2.5/site-packages
instead
(maybe I could have reconfigured this, anyway)
but I don't know why, altough
/usr/local/lib64/python2.5/site-packages/pycuda/
/usr/local/lib64/python2.5/site-packages/pytools-9-py2.5.egg/pytools/
live outside obvious scope, the pycuda demos
hello_gpu.py
demo.py
demo_struct.py
dump_properties.py
demo_elementwise.py
ran.
But for gl_interop.py
I got "No module named vertex_buffer_object"
Obviously OpenGL.GL.ARB.vertex_buffer_object
is new in python-opengl ~ Version 3.
There are only rpms for Version 2.0.something for SuSE 11.0
I got new source from http://pyopengl.sourceforge.net
build and install, obviously to
/usr/local/lib64/python2.5/site-packages/OpenGL/
However, gl_interop.py did not run until I did
export PYTHONPATH=/usr/local/lib64/python2.5/site-packages/
(was PYTHONPATH="" before)
maybe this is since there is still the old python-opengl-2.0.1.09-224.1
/usr/lib64/python2.5/site-packages/OpenGL/GL/ARB/ ...with-no-vertex-buffer-in-there
in the way which is caught before.
But to figure it out I'm definitely lacking sufficient python experience.
>
> > If you like and give me an wiki account, I'd go to share my experience.
>
> No account required. (though you can create one yourself) Please do share.
hm, might give it a try.
I think best I could offer was be to prepare an own SuSE page with my
experience.
It all comes down to different ways and places where stuff is stored.
But I think my approach is not the best one, in the view back it were better
to configure new stuff so that it meets SuSE structure. Maybe.
Well, but this might break other dependencies?
Smells like big 'Baustelle'...
So if your expectation of quality on your wiki is not too high, I'll post my
experience there.
Wolfgang
>
> Andreas
9 years, 12 months
Re: [PyCUDA] trouble with pycuda-0.93.1rc2 - test_driver.py, etc.
by Janet Jacobsen
Hi, Andreas. I ran
ldd /usr/common/usg/python/2.6.4/lib/python2.6/site-packages
/pycuda-0.93.1rc2-py2.6-linux-x86_64.egg/pycuda/_driver.so
and got
> libboost_python.so.1.40.0 =>
> /usr/common/usg/boost/1_40_0/pool/lib/libboost_python.so.1.40.0
> (0x00002b259cac6000)
> libboost_thread.so.1.40.0 =>
> /usr/common/usg/boost/1_40_0/pool/lib/libboost_thread.so.1.40.0
> (0x00002b259cd15000)
> libcuda.so.1 => /usr/lib64/libcuda.so.1 (0x00002b259cf43000)
> libstdc++.so.6 => /usr/common/usg/gcc/4.4.2/lib64/libstdc++.so.6
> (0x00002b259d3df000)
> libm.so.6 => /lib64/libm.so.6 (0x00002b259d6eb000)
> libgcc_s.so.1 => /usr/common/usg/gcc/4.4.2/lib64/libgcc_s.so.1
> (0x00002b259d96e000)
> libpthread.so.0 => /lib64/libpthread.so.0 (0x00002b259db85000)
> libc.so.6 => /lib64/libc.so.6 (0x00002b259dda0000)
> libutil.so.1 => /lib64/libutil.so.1 (0x00002b259e0f6000)
> libdl.so.2 => /lib64/libdl.so.2 (0x00002b259e2fa000)
> librt.so.1 => /lib64/librt.so.1 (0x00002b259e4fe000)
> libz.so.1 => /usr/lib64/libz.so.1 (0x00002b259e707000)
> /lib64/ld-linux-x86-64.so.2 (0x000000316ec00000)
Does this help?
Neither /usr/include/python2.4 nor /usr/include is not part of my
PATH, so it would not seem that I am picking up the headers for
the default version of python.
Thanks,
Janet
P.S. Sorry if this should be off-list, but email sent to
lists(a)monster.tiker.net is returned to me.
Andreas Klöckner wrote:
> On Freitag 20 November 2009, Janet Jacobsen wrote:
>
>> Hi, Andreas. Here's what I get
>>
>>
>>> % ldd /usr/common/usg/boost/1_40_0/pool/lib/libboost_python.so.1.40.0
>>> libutil.so.1 => /lib64/libutil.so.1 (0x00002b240c2ca000)
>>> libpthread.so.0 => /lib64/libpthread.so.0 (0x00002b240c4cd000)
>>> libdl.so.2 => /lib64/libdl.so.2 (0x00002b240c6e8000)
>>> librt.so.1 => /lib64/librt.so.1 (0x00002b240c8ed000)
>>> libstdc++.so.6 => /usr/common/usg/gcc/4.4.2/lib64/libstdc++.so.6
>>> (0x00002b240caf6000)
>>> libm.so.6 => /lib64/libm.so.6 (0x00002b240ce02000)
>>> libgcc_s.so.1 => /usr/common/usg/gcc/4.4.2/lib64/libgcc_s.so.1
>>> (0x00002b240d086000)
>>> libc.so.6 => /lib64/libc.so.6 (0x00002b240d29c000)
>>> /lib64/ld-linux-x86-64.so.2 (0x000000316ec00000)
>>>
>
> Turns out you're not missing anything--my libboost_python ldd output
> looks exactly the same.
>
> Try running this here:
>
> ldd
> /usr/common/usg/python/2.6.4/lib/python2.6/site-packages/pycuda-0.93.1rc2-
>
> py2.6-linux-x86_64.egg/pycuda/
>
> and see if this brings up incriminating evidence of mixed versions.
> Another possibility: You may have two sets of Python headers available
> on your include path.
>
> HTH,
> Andreas
>
9 years, 12 months
Re: [PyCUDA] Build Problems on SuSE 11.0, x86_64 - cannot find -llibboost_python-mt
by Wolfgang Rosner
AAAUUUUUAAAAA
this really hurts:-\\\\\\\\\
shold I do a c tutorial first (the last one was 25+ years back...)?
so:
:~> vi siteconf.py
BOOST_INC_DIR = ['/usr/include']
BOOST_LIB_DIR = ['/usr/lib64']
BOOST_COMPILER = 'gcc43'
BOOST_PYTHON_LIBNAME = ['boost_python-mt']
BOOST_THREAD_LIBNAME = ['boost_thread-mt']
CUDA_TRACE = False
CUDA_ENABLE_GL = True
CUDADRV_LIB_DIR = ['/usr/lib64']
CUDADRV_LIBNAME = ['cuda']
CXXFLAGS = []
LDFLAGS = []
python setup.py build
... works fine, we have a
build/lib.linux-x86_64-2.5/pycuda/_driver.so
Much thanks!
===============================
next problem:
cd examples/
python hello_gpu.py
.... pytools not found
check http://wiki.tiker.net/PyCuda/Installation/Linux
check numpy - is installed
..
su -c "make install"
.... still pytools not found
logoff / logon (some envrionment stuff?)
.... still pytools not found
gooooogle,
Ah, you always expect pytools to be installed on your machines ;-)
fiddle around how to do undocumented setup
su
python setup.py install
exit
cd test/
python test.py
... throws some errors
python test-prefork.py
.... just let's you wait some minutes and then prints some cuda version -
weared, but don't care
cd pycuda/test/
python hello_gpu.py
get a bunch of zeros ans feel happy :-)))
OK, for me it works now, but peomple might be even more (and earlier) happy if
the pytools issue had been mentioned in the setup wiki.
If you like and give me an wiki account, I'd go to share my experience.
Yours
Wolfgang Rosner
9 years, 12 months
