PyCUDA November 2009

pycuda@tiker.net

16 participants
24 discussions

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

10 years, 4 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

10 years, 7 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

10 years, 7 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...

10 years, 7 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

10 years, 7 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.

10 years, 7 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.eg… 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

10 years, 7 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

10 years, 7 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 >

10 years, 7 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

10 years, 7 months

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

PyCUDA November 2009