Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Import Error When run convnet.py #17

Open
jasonustc opened this issue Dec 5, 2014 · 15 comments
Open

Import Error When run convnet.py #17

jasonustc opened this issue Dec 5, 2014 · 15 comments

Comments

@jasonustc
Copy link

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.

@windpls
Copy link

windpls commented Jan 11, 2015

Hey, I got the same error.

@heavyd93
Copy link

I get the same error, have any of you solved it?

@dnouri
Copy link
Owner

dnouri commented Jan 16, 2015

@kashif, any ideas?

@jasonustc
Copy link
Author

Finally, I use the "Makefile", "build.sh" and "common-gcc-cuda-4.0.mk" from
alex cuda-convnet,
and it works

@kashif
Copy link
Contributor

kashif commented Jan 17, 2015

@jasonustc can you let me know which version of CUDA and linux distro you are using so I can debug this? thanks!

@jasonustc
Copy link
Author

My version of CUDA is V6.0.1 and linux destro is ubuntu 14.10,
thanks.

@kashif
Copy link
Contributor

kashif commented Jan 17, 2015

@jasonustc great and just using the normal cmake via apt I guess?

ok firing up my ubuntu box 🐧

@jasonustc
Copy link
Author

Yeah, I just install cmake using the apt-get way...

@kashif
Copy link
Contributor

kashif commented Jan 18, 2015

@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?

@kashif
Copy link
Contributor

kashif commented Jan 18, 2015

@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!

@jasonustc
Copy link
Author

@kashif the output of BLAS_LIBRARIES is:

BLAS_LIBRARIES: /usr/lib64/atlas/libf77blas.so/usr/lib64/atlas/libatlas.so

@jasonustc
Copy link
Author

@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)

@heavyd93
Copy link

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.

@kashif
Copy link
Contributor

kashif commented Jan 20, 2015

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...

@kashif
Copy link
Contributor

kashif commented Jan 24, 2015

@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  .

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants