undefined symbol error
by Chris
Hey Andreas,
I am having a similar issue that Kambiz Tavabi was having. Here is the error
(I have pycuda on anaconda2 just like Kambiz)
File "main_class.py", line 17, in <module>
import pycuda.gl as cuda_gl
File
"/home/uchytilc/anaconda2/lib/python2.7/site-packages/pycuda-2016.1.2-py2.7-linux-x86_64.egg/pycuda/gl/__init__.py",
line 2, in <module>
import pycuda._driver as _drv
ImportError:
/home/uchytilc/anaconda2/lib/python2.7/site-packages/pycuda-2016.1.2-py2.7-linux-x86_64.egg/pycuda/_driver.so:
undefined symbol: _ZNSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEED1Ev
The weird thing is that I have some files that are having this problem and
some that are not, with identical import statements.
import sys
from OpenGL.GL import *
from OpenGL.GLUT import *
from OpenGL.GLU import *
from OpenGL.GL.ARB.vertex_buffer_object import *
from OpenGL.GL.ARB.pixel_buffer_object import *
import pycuda.gl as cuda_gl
import pycuda.driver as cuda_driver
The files that are experiencing this issue are all files that run this
import statement right at the top in the main.py file, the one I initialize
from. The one that doesn't hit this error has the import statements in a
second file that is being imported with an __init__.py file. Not sure if
this is pure coincidence or not but I figured it was worth bringing up.
--
View this message in context: http://pycuda.2962900.n2.nabble.com/undefined-symbol-error-tp7575758.html
Sent from the PyCuda mailing list archive at Nabble.com.
1 year, 12 months
Installation on Ubuntu 14.04
by Guillaume Androz
Hi,
I'm trying to install pyCuda 2016.1.2 on Mint 17.3 (same as Ubuntu 14.04),
I follow the procedure found at
https://wiki.tiker.net/PyCuda/Installation/Linux/Ubuntu, but I keep having
the same error
In file included from src/cpp/cuda.cpp:1:0:
src/cpp/cuda.hpp:14:18: fatal error: cuda.h: No such file or directory
#include <cuda.h>
^
compilation terminated.
error: command 'gcc' failed with exit status 1
make: *** [all] Error 1
>> echo $PATH
/usr/local/cuda-8.0/bin:/usr/local/bin/anaconda/bin:/usr/local/bin/anaconda/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games
>> echo $CUDA_ROOT
/usr/local/cuda-8.0
2 years
Re: [PyCUDA] CUDA driver compute mode
by Andreas Kloeckner
Kambiz Tavabi <ktavabi(a)uw.edu> writes:
> Following TB from test_driver.py with 2016.1.2 build on OS X 10.11 with
> CUDA 8 V8.0.61; was able to workaround by changing
>
> if drv.Context.get_device().compute_mode == drv.compute_mode.*EXCLUSIVE*:
>
> to
>
> if drv.Context.get_device().compute_mode == drv.compute_mode.
> *EXCLUSIVE_PROCESS*:
>
> in test_dirver.py
>
> Is this expected?
Fixed in git, but not yet released:
https://github.com/inducer/pycuda/commit/255644ad802a20191e31bc15f4fd46e6...
Thanks for the report,
Andreas
2 years
CUDA driver compute mode
by Kambiz Tavabi
Following TB from test_driver.py with 2016.1.2 build on OS X 10.11 with
CUDA 8 V8.0.61; was able to workaround by changing
if drv.Context.get_device().compute_mode == drv.compute_mode.*EXCLUSIVE*:
to
if drv.Context.get_device().compute_mode == drv.compute_mode.
*EXCLUSIVE_PROCESS*:
in test_dirver.py
Is this expected?
________________________ TestDriver.test_multi_context
_________________________
args = (<test_driver.TestDriver instance at 0x10fa18dd0>,), kwargs = {}
pycuda = <module 'pycuda' from
'/Users/ktavabi/anaconda2/lib/python2.7/site-packages/pycuda-2016.1.2-py2.7-macosx-10.5-x86_64.egg/pycuda/__init__.pyc'>
ctx = <pycuda._driver.Context object at 0x10e9a59b0>
clear_context_caches = <function clear_context_caches at 0x10dc52e60>
collect = <built-in function collect>
def f(*args, **kwargs):
import pycuda.driver
# appears to be idempotent, i.e. no harm in calling it more than
once
pycuda.driver.init()
ctx = make_default_context()
try:
assert isinstance(ctx.get_device().name(), str)
assert isinstance(ctx.get_device().compute_capability(), tuple)
assert isinstance(ctx.get_device().get_attributes(), dict)
> inner_f(*args, **kwargs)
../../../anaconda2/lib/python2.7/site-packages/pycuda-2016.1.2-py2.7-macosx-10.5-x86_64.egg/pycuda/tools.py:460:
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
_ _
self = <test_driver.TestDriver instance at 0x10fa18dd0>
@mark_cuda_test
def test_multi_context(self):
if drv.get_version() < (2,0,0):
return
if drv.get_version() >= (2,2,0):
> if drv.Context.get_device().compute_mode ==
drv.compute_mode.EXCLUSIVE:
E AttributeError: type object 'compute_mode' has no attribute
'EXCLUSIVE'
test_driver.py:638: AttributeError
=============== 1 failed, 25 passed, 2 skipped in 37.73 seconds
================
------------------------------------------------------------
Kambiz Tavabi PhD
Institute for Learning & Brain Sciences
1715 Columbia Road N
Portage Bay Building
Box 357988
University of Washington
Seattle, WA 98195-7988
Tel: 206-685-6173
------------------------------------------------------------
*Confidentiality Notice: Because email is not secure, please be aware that
we cannot guarantee the confidentiality of information sent by email. If
you are not the intended recipient of this email, please notify the sender
by reply email, and then destroy all copies of the message and any
attachments.*
2 years
Re: [PyCUDA] [PyOpenCL] New architectures for PyOpenCL in Debian
by Tomasz Rybak
On Mon, 2017-02-13 at 10:24 +0000, Vedran Miletić wrote:
> Tomasz,
>
> half a year ago there was one person who came to #radeon on Freenode
> and talked about open source radeon driver stack almost working on
> ppc64 (I have no information whether the bugs have been addressed
> since, but I would presume they have). Would it be possible to
> provide ppc64 package for PyOpenCL as well?
>
In theory it's possible.
But according to Debian Policy 2.2.1 package must not require software
not present in Debian for execution.
https://www.debian.org/doc/debian-policy/ch-archive.html#s-main
Currently there is no OpenCL ICD for ppc64 in Debian - so I cannot
upload PyOpenCL for that architecture.
It would be much easier to just build PyOpenCL for all architectures,
but to be following Policy I need to manually maintain list of
architectures for which we have ICDs.
Best regards.
--
Tomasz Rybak, Debian Maintainer <tomasz.rybak(a)post.pl>
GPG: A481 824E 7DD3 9C0E C40A 488E C654 FB33 2AD5 9860
http://member.acm.org/~tomaszrybak
2 years, 1 month
Re: [PyCUDA] [PyOpenCL] New architectures for PyOpenCL in Debian
by Tomasz Rybak
On Mon, 2016-11-21 at 22:46 -0600, Andreas Kloeckner wrote:
[ cut ]
> At the same time I have a question for you Andreas. There will be
> > freeze of Stretch on 2017-01-05. I’d like to upload PyOpenCL and
> > PyCUDA
> > in mid-December, and those versions will be versions for Stretch.
> > Do
> > you plan new releases, or should I just take snapshots from git?
>
> I'll do a 2016.2.1 mid-December.
>
Quick update.
PyOpenCL from 2016-11-30 (commit
19015994653dffe2ee407271e19a46e1d6a62796) is in Debian testing,
for architectures amd64, arm64, armhf, i386, and amd64 and i386
for kFreeBSD. There is no release-critical errors against it
which means that this version of PyOpenCL should be in Debian Stretch.
As for PyCUDA, the version in Debian is from 2016-10-24,
commit 50457813cfe3eb359a230c4e1e546ccdef9947f8.
It's only available for amd64. I tried to build package
for ppc64el, but wasn't able to properly configure cross-compiler.
As Debian is in deep freeze now, I won't upload new versions
of packages Stretch release. Using this time I'll try to
make ppc64el PyCUDA - but it's not something I'll focus on entirely.
If you have questions or suggestions regarding packages,
please let me know.
Best regards.
--
Tomasz Rybak, Debian Maintainer <tomasz.rybak(a)post.pl>
GPG: A481 824E 7DD3 9C0E C40A 488E C654 FB33 2AD5 9860
http://member.acm.org/~tomaszrybak
2 years, 1 month
