[PyCUDA] Build Problems on SuSE 11.0, x86_64 - cannot find -llibboost_python-mt
Hello, Andreas Klöckner, I can't get pycuda to build on my box. I tried at least 10 times, try to reproduce details now. In the archive, there was a similar thread with a SuSE 11.1 64 bit box , posted by Jonghwan Rhee http://article.gmane.org/gmane.comp.python.cuda/955 but that did not really provide a solution. cannot find -llibboost_python-mt although the file is in place == Details: openSUSE 11.0 (X86-64) kernel: Linux version 2.6.25.18-0.2-debug (ge...@buildhost) (gcc version 4.3.1 20080507 (prerelease) [gcc-4_3-branch revision 135036] (SUSE Linux) ) #1 SMP 2008-10-21 16:30:26 +0200 - what I did: load snapshot :~tar -xvzf pycuda-release-0.93.tar.gz :~cd pycuda/ :~cp ../siteconf.py . (get config from previous trials) :~./configure.py 1st configure call: :~./configure.py Traceback (most recent call last): File ./configure.py, line 3, in module from aksetup_helper import configure_frontend File /home/wrosner/test/cuda/pycuda/pycuda/aksetup_helper.py, line 3, in module distribute_setup.use_setuptools() ... File /home/wrosner/test/cuda/pycuda/pycuda/distribute_setup.py, line 228, in _rename_path os.rename(path, new_name) OSError: [Errno 13] Permission denied running again :~./configure.py *** I'm taking the configured values as defaults looks OK so far :~python setup.py build ... some gcc runs seem ok but then . g++ -pthread -shared build/temp.linux-x86_64-2.5/src/cpp/cuda.o build/temp.linux-x86_64-2.5/src/cpp/bitlog.o build/temp.linux-x86_64-2.5/src/wrapper/wrap_cudadrv.o build/temp.linux-x86_64-2.5/src/wrapper/mempool.o build/temp.linux-x86_64-2.5/src/wrapper/wrap_cudagl.o -L/usr/lib64 -L/usr/lib64 -L/usr/lib64 -llibboost_python-mt -llibboost_thread-mt -llibcuda -lpython2.5 -o build/lib.linux-x86_64-2.5/pycuda/_driver.so /usr/lib64/gcc/x86_64-suse-linux/4.3/../../../../x86_64-suse-linux/bin/ld: cannot find -llibboost_python-mt collect2: ld returned 1 exit status error: command 'g++' failed with exit status 1 - The file it is there without doubt: :~la /usr/lib64/libboost_python-mt.so lrwxrwxrwx 1 root root 25 21. Nov 00:57 /usr/lib64/libboost_python-mt.so - libboost_python.so.1.39.0 == I tried different sym link names, fiddling with pathes and names in the siteconf.py - always same picture. I tried to call the g++ manually with modified params, even with full path -l/usr/lib64/libboost_python-mt.so still does not want to find it while fiddling, I came across some boost_python in /usr/lib/, but there I got complaint incompatible or so. Found that there was a 586 package installed, which I have removed. But at least, the ld could _find_ the file. Seems like a problem with the 64 bit architecture? Can I build pycuda / boost in 32-bit-mode without screwing my whole system??? == :~cat siteconf.py BOOST_INC_DIR = ['/usr/include'] BOOST_LIB_DIR = ['/usr/lib64'] BOOST_COMPILER = 'gcc43' BOOST_PYTHON_LIBNAME = ['libboost_python-mt'] BOOST_THREAD_LIBNAME = ['libboost_thread-mt'] CUDA_TRACE = False CUDA_ENABLE_GL = True CUDADRV_LIB_DIR = ['/usr/lib64'] CUDADRV_LIBNAME = ['libcuda'] CXXFLAGS = [] LDFLAGS = [] = :~g++ --version g++ (SUSE Linux) 4.3.1 20080507 (prerelease) [gcc-4_3-branch revision 135036] rpm -qa | grep boost libboost_graph1_36_0-1.36.0-11.1 libboost_thread1_39_0-1.39.0-6.1 boost-license-1.36.0-11.1 libboost_system1_36_0-1.36.0-11.1 libboost_system1_39_0-1.39.0-6.1 boost1_36-devel-1.36.0-0.pm.1.1 libboost_test1_36_0-1.36.0-11.1 libboost_signals1_39_0-1.39.0-6.1 libboost_math1_39_0-1.39.0-6.1 boost-devel-1.39.0-6.1 libboost_regex1_36_0-1.36.0-11.1 libboost_python1_39_0-1.39.0-6.1 libboost_graph1_39_0-1.39.0-6.1 boost-jam-3.1.14-51.1 libboost_math1_36_0-1.36.0-11.1 libboost_filesystem1_36_0-1.36.0-11.1 boost1_36-1.36.0-0.pm.1.1 libboost_test1_39_0-1.39.0-6.1 libboost_date_time1_36_0-1.36.0-11.1 libboost_wave1_39_0-1.39.0-6.1 libboost_iostreams1_39_0-1.39.0-6.1 libboost_program_options1_39_0-1.39.0-6.1 libboost_iostreams1_36_0-1.36.0-11.1 libboost_serialization1_36_0-1.36.0-11.1 boost-license1_39_0-1.39.0-6.1 libboost_serialization1_39_0-1.39.0-6.1 libboost_mpi1_39_0-1.39.0-6.1 libboost_signals1_36_0-1.36.0-11.1 boost-doc-1.39.0-6.1 libboost_filesystem1_39_0-1.39.0-6.1 libboost_program_options1_36_0-1.36.0-11.1 libboost_date_time1_39_0-1.39.0-6.1 libboost_regex1_39_0-1.39.0-6.1 is the version mix a problem? standard on my dist ist v34 for boost, highest I found was 36. The lowest for libboost_python and libboost_thread I could find were v39 however. == rerun build: :~ python setup.py build Scanning installed packages Setuptools installation detected at /home/wrosner/test/cuda/pycuda/pycuda Non-egg installation Removing elements out
Re: [PyCUDA] Build Problems on SuSE 11.0, x86_64 - cannot find -llibboost_python-mt
On Samstag 21 November 2009, Wolfgang Rosner wrote: Hello, Andreas Klöckner, I can't get pycuda to build on my box. I tried at least 10 times, try to reproduce details now. In the archive, there was a similar thread with a SuSE 11.1 64 bit box , posted by Jonghwan Rhee http://article.gmane.org/gmane.comp.python.cuda/955 but that did not really provide a solution. cannot find -llibboost_python-mt although the file is in place First, all that configure.py does is edit siteconf.py--no need to rerun it once sitconf.py is in place. Second, -lsomething implicitly looks for libsomething.so. No need to specify the lib prefix. HTH, Andreas signature.asc Description: This is a digitally signed message part. ___ PyCUDA mailing list PyCUDA@tiker.net http://tiker.net/mailman/listinfo/pycuda_tiker.net
Re: [PyCUDA] Build Problems on SuSE 11.0, x86_64 - cannot find -llibboost_python-mt
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? 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. Andreas signature.asc Description: This is a digitally signed message part. ___ PyCUDA mailing list PyCUDA@tiker.net http://tiker.net/mailman/listinfo/pycuda_tiker.net
Re: [PyCUDA] trouble with pycuda-0.93.1rc2 - test_driver.py, etc.
Hi, Andreas. Thanks for this information and your recommendation to rebuild boost. I will give it a try, though my effort to do so may be delayed a week due to travel. I will report back when I have rebuilt boost and re-tested. Many thanks, Janet On 11/20/2009 8:34 PM, Andreas Klöckner wrote: On Freitag 20 November 2009, Janet Jacobsen wrote: Hi, Andreas. Last question, first: when I hit the reply button, your email address shows up as li...@monster.tiker.net. Huh, weird. I need to look into that. Thanks for letting me know. I take this to mean that I need to rebuild python and specify --enable-unicode=ucs4 and --enable-shared when I run the configure step. Are there other configure options that I should include? No, I think that would be the wrong way around. You should rebuild Boost. Since Boost seems to have picked up a UCS4 Python, that must've been the system-wide 2.4 one. So even if you rebuild Python to match Boost's UCS'iness, you'll still be building against a mismatched version of Python (2.4 vs 2.6, and who knows what else is different). In the best case, that's is going to give you something marginally working that crashes a lot. Andreas PS: Out of curiosity: Why on earth does Python support two different UCS widths? ___ PyCUDA mailing list PyCUDA@tiker.net http://tiker.net/mailman/listinfo/pycuda_tiker.net
Re: [PyCUDA] Build Problems on SuSE 11.0, now Pytools not found
Hello, Andreas, Am Samstag, 21. November 2009 20:00:10 schrieb pycuda-requ...@tiker.net: Message: 3 Date: Sat, 21 Nov 2009 13:39:13 -0500 From: Andreas Kl?ckner li...@informa.tiker.net Subject: Re: [PyCUDA] Build Problems on SuSE 11.0, x86_64 - cannot find -llibboost_python-mt To: pycuda@tiker.net Message-ID: 200911211339.19819.li...@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 ___ PyCUDA mailing list PyCUDA@tiker.net http://tiker.net/mailman/listinfo/pycuda_tiker.net
Re: [PyCUDA] Build Problems on SuSE 11.0, now Pytools not found
On Samstag 21 November 2009, Wolfgang Rosner wrote: 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 ? make install invokes python setup.py install. That shouldn't have been it. (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) 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' hm, might give it a try. I think best I could offer was be to prepare an own SuSE page with my experience. Sure--just add a subpage under http://wiki.tiker.net/PyCuda/Installation/Linux (like the one for Ubuntu) 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. That's the whole point of a Wiki: information of questionable quality that people improve as they use it. It's a knowledge retention tool. Andreas signature.asc Description: This is a digitally signed message part. ___ PyCUDA mailing list PyCUDA@tiker.net http://tiker.net/mailman/listinfo/pycuda_tiker.net
