cuda-convnet
cuda-convnet copied to clipboard
Import Error When run convnet.py
I tried the given CMakeLists.txt and built the _covnet.so successfully, but When I tried to run "python convnet.py ..." . An error arose: Import Error: undefined symbol: cblas_sgemm. It seems that "import("_convnet.so") " in convnet.py can not find the definition of cblas_sgemm. Even after I export the path of "libbblas.so" to "LD_LIBRARY_PATH" , the error still exists. What should I do to solve this problem?
Thanks.
Hey, I got the same error.
I get the same error, have any of you solved it?
@kashif, any ideas?
Finally, I use the "Makefile", "build.sh" and "common-gcc-cuda-4.0.mk" from alex cuda-convnet, and it works
@jasonustc can you let me know which version of CUDA and linux distro you are using so I can debug this? thanks!
My version of CUDA is V6.0.1 and linux destro is ubuntu 14.10, thanks.
@jasonustc great and just using the normal cmake via apt I guess?
ok firing up my ubuntu box :penguin:
Yeah, I just install cmake using the apt-get way...
@jasonustc sorry ignore my previous comment... can you do the following on your Cmake compiled _convnet.so
:
$ ldd _convnet.so
...
and send me the output?
@jasonustc ok I think i can reproduce the problem... can you add the following line into your main CMakeLists.txt
file somewhere:
...
MESSAGE( STATUS "BLAS_LIBRARIES: " ${BLAS_LIBRARIES})
...
and then cmake .
and let me know what the output is, thanks!
@kashif the output of BLAS_LIBRARIES is:
BLAS_LIBRARIES: /usr/lib64/atlas/libf77blas.so/usr/lib64/atlas/libatlas.so
@kashif I run ldd _convnet.so
and the output is:
linux-vdso.so.1 => (0x00007fff839ff000)
libcudart.so.6.0 => /usr/local/cuda-6.0/lib64/libcudart.so.6.0 (0x00007f47f80cc000)
libpython2.6.so.1.0 => /usr/lib64/libpython2.6.so.1.0 (0x00007f47f7d25000)
libf77blas.so.3 => /usr/lib64/atlas/libf77blas.so.3 (0x00007f47f7b06000)
libatlas.so.3 => /usr/lib64/atlas/libatlas.so.3 (0x00007f47f74aa000)
libcublas.so.6.0 => /usr/local/cuda-6.0/lib64/libcublas.so.6.0 (0x00007f47f5ad1000)
libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007f47f57cb000)
libm.so.6 => /lib64/libm.so.6 (0x00007f47f5535000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f47f531e000)
libc.so.6 => /lib64/libc.so.6 (0x00007f47f4f8a000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f47f4d86000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f47f4b68000)
librt.so.1 => /lib64/librt.so.1 (0x00007f47f4960000)
libutil.so.1 => /lib64/libutil.so.1 (0x00007f47f475d000)
libgfortran.so.3 => /usr/lib64/libgfortran.so.3 (0x00007f47f446a000)
/lib64/ld-linux-x86-64.so.2 (0x00000037ffe00000)
Hi guys,
I am having the same problem, but I am running openSUSE 12.2 and CUDA 5. and these are the outputs I get:
BLAS_LIBRARIES: /usr/lib64/libblas.so
and
linux-vdso.so.1 (0x00007fff71bff000)
libcudart.so.5.0 => /usr/local/cuda/lib64/libcudart.so.5.0 (0x00007fe9599b4000)
libcuda.so.1 => /usr/lib64/libcuda.so.1 (0x00007fe958d92000)
libpython2.7.so.1.0 => /usr/lib64/libpython2.7.so.1.0 (0x00007fe9589f4000)
libblas.so.3 => /usr/lib64/libblas.so.3 (0x00007fe95879b000)
libcublas.so.5.0 => /usr/local/cuda/lib64/libcublas.so.5.0 (0x00007fe954da5000)
libstdc++.so.6 => /usr/lib64/libstdc++.so.6 (0x00007fe954a9e000)
libm.so.6 => /lib64/libm.so.6 (0x00007fe9547a7000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fe954590000)
libc.so.6 => /lib64/libc.so.6 (0x00007fe9541eb000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007fe953fe7000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fe953dca000)
librt.so.1 => /lib64/librt.so.1 (0x00007fe953bc2000)
libz.so.1 => /lib64/libz.so.1 (0x00007fe9539ac000)
libutil.so.1 => /lib64/libutil.so.1 (0x00007fe9537a8000)
libgfortran.so.3 => /usr/lib64/libgfortran.so.3 (0x00007fe953492000)
/lib64/ld-linux-x86-64.so.2 (0x00007fe95abd3000)
libquadmath.so.0 => /usr/lib64/libquadmath.so.0 (0x00007fe95325b000)
hope this is of some use.
thanks.
ok so investigating it further it seems the FindBLAS
from cmake is a bit buggy in that it fails to find the correct cblas
libs for the situations when for example atlas
is installed, or I suspect even openblas
etc.
@jasonustc can you make sure since you have atlas
as your default blas
that it is configured properly via the update-alternatives
command?
One solution might be to have our own FindBLAS.cmake
just like a bunch of other projects... we just need to find a recent one that works with all these new alternatives...
@jasonustc @windpls @heavyd93 another solution, as stated in the README, is to set the library location explicitly, e.g.:
$ cmake -DBLAS_LIBRARIES=/usr/lib/atlas-base/libcblas.so .