cuDNN library not found when building tensorflow example with bazel - c++

I tried to test the tensorflow example, with c++ api, described here: https://www.tensorflow.org/tutorials/image_recognition#usage_with_the_c_api
I was able to install tensorflow from sources, but when I wanted to build the example with: bazel-bin/tensorflow/examples/label_image/label_image
I get this error :
ERROR: /home/user/tensorflow_sources/tensorflow/tensorflow/examples/label_image/BUILD:14:1: Linking of rule '//t
ensorflow/examples/label_image:label_image' failed (Exit 1)
/usr/bin/ld: warning: libcudnn.so.6, needed by bazel-out/k8-opt/bin/_solib_local/_U_S_Stensorflow_Sexamples_Slabel_
Uimage_Clabel_Uimage___Utensorflow/libtensorflow_framework.so, not found (try using -rpath or -rpath-link)
/usr/bin/ld: warning: libcufft.so.8.0, needed by bazel-out/k8-opt/bin/_solib_local/_U_S_Stensorflow_Sexamples_Slabe
l_Uimage_Clabel_Uimage___Utensorflow/libtensorflow_framework.so, not found (try using -rpath or -rpath-link)
/usr/bin/ld: warning: libcurand.so.8.0, needed by bazel-out/k8-opt/bin/_solib_local/_U_S_Stensorflow_Sexamples_Slab
el_Uimage_Clabel_Uimage___Utensorflow/libtensorflow_framework.so, not found (try using -rpath or -rpath-link)
The issue is exactly the same as described here: https://github.com/tensorflow/tensorflow/issues/15029
But the solution is not clear :
I need configure LPATH to include path of libcudnn.so. Although I
put the lib at the standard location.
What is this LPATH variable ? What is the standard location for this library? Because for me actually, it is /usr/local/cuda
I tried to reconfigure many times my tensorflow installation, I exported the LD_LIBRARY_PATH with the correct path to the folder containing the file libcudnn.so.6 but none of these solution worked.
My configuration :
tensorflow r1.4
Cuda 8.0
cuDNN 6.0
bazel 0.9.0

Related

Unable to compile C++ code with simulink with libmwfl.so errors

We are trying to compile some C++ code with simulink /matlab . We are getting some libmwfl.so errors. We have made sure that the files are linked . Also on doing a search for the file libmwfl.so it seems that it exists. So at the moment a bit clueleess. The error log is as below.
/usr/bin/ld: warning: libmwfl.so, needed by /usr/local/MATLAB/R2015b/bin/glnxa64/libmat.so, not found (try using -rpath or -rpath-link)
/usr/bin/ld: warning: libmwi18n.so, needed by /usr/local/MATLAB/R2015b/bin/glnxa64/libmat.so, not found (try using -rpath or -rpath-link)
Regards

/usr/bin/ld: warning: libavcodec.so.53, needed by xxx not found

I am trying to compile a given source code with makefile, but the problem I am facing is the fact that it uses libavcodec.so.53. The version installed is 54, the libavutil and libavformat versions are also different from the Linux version. I can't change the version of them in Linux because I don't have root access. So I will use a local folder where opencv, libavutil.so, libavformat.so and libavcodec.so.53 are.
I put this folder name into the makefile.config as it follows:
INCLUDE_DIRS := $(PYTHON_INCLUDE) /usr/local/include /home/me/lib
LIBRARY_DIRS := $(PYTHON_LIB) /usr/local/lib /usr/lib /usr/local /home/me/lib
But when I compile it I have the following errors:
/usr/bin/ld: warning: libavcodec.so.53, needed by
/home/anselmo/lib/lib/libopencv_highgui.so, not found (try using -
rpath or -rpath-link)
/usr/bin/ld: warning: libavformat.so.53, needed by
/home/me/lib/libopencv_highgui.so, not found (try using -rpath or -rpath-link)
/usr/bin/ld: warning: libavutil.so.51, needed by
/home/me/lib/libopencv_highgui.so, not found (try using -rpath or rpath-link)
/home/anselmo/lib/lib/libopencv_highgui.so: undefined reference to
`avcodec_flush_buffers#LIBAVCODEC_53'
/home/me/lib/libopencv_highgui.so: undefined reference to
`av_freep#LIBAVUTIL_51'
/home/me/lib/libopencv_highgui.so: undefined reference to
`av_read_frame#LIBAVFORMAT_53'
libavutil.so.51, libavformat.so.53 and libavcodec.so.53 are in /home/me/lib as indicated in the makefile. How to show linux how to use them instead of the ones installed in the machine? again, I cannot be root.

Issue with building Teigha SDK: 'cannot find -lJpeg'

I'm trying to build Teigha SDK in Ubuntu 12.04. I got the following linking error:
/usr/bin/ld: cannot find -lJpeg
/usr/bin/ld: cannot find -lJpeg
libjpeg has alredy been installed on my machine. What else is missing?
libjpeg has alredy been installed on my machine. What else is missing?
/usr/bin/ld: cannot find -lJpeg
^
Note the uppercase letter! The linker is missing a libJpeg.a (or other archive format) file, or an appropriate -L<path> option to resolve it.

How to automatically link to dependencies of shared library

I am trying to build a small Qt (C++) GUI application on Linux but it fails to build with numerous linker errors, complaining about missing dependencies for the Qt library I am linking against. I used ldd on the Qt libraries to verify that the libraries are indeed there - and they are.
My problem seems to be related to the discussion in this thread:
Linking dependencies of a shared library
And while that thread helped me identify my precise problem, it seems that the conclusion of that thread was that my application should link!
The application is compiled with the following command:
g++ -m64 -Wl,-O1 -o Executable some-object.o some-other-object.o -lQtCore -lQtGui -lQtXml -L/usr/lib64 -L/usr/X11R6/lib64 -lpthread
Running this generates warnings of the following form, and linking eventually fails with undefined reference errors (to symbols defined in the 'missing' libraries):
.../ld: warning: libglib-2.0.so.0, needed by /usr/lib64/libQtGui.so, not found (try using -rpath or -rpath-link)
.../ld: warning: libpng14.so.14, needed by /usr/lib64/libQtGui.so, not found (try using -rpath or -rpath-link)
.../ld: warning: libz.so.1, needed by /usr/lib64/libQtGui.so, not found (try using -rpath or -rpath-link)
.../ld: warning: libfreetype.so.6, needed by /usr/lib64/libQtGui.so, not found (try using -rpath or -rpath-link)
and so on (in total there are 18 dependencies that could not be found.)
I can get this to compile if I go and explicitly add -lglib, -lpng14, -lz -lfreetype and so on, but as I mentioned there are 18 dependencies - and I would rather not do that. It also seems that I should not have to do it.
I have compiled the same project on my laptop computer which uses the exact same Linux Distro (openSuse 12.2) without any troubles. All libraries, including Qt, were installed from the distro repositories.
I think this might be some sort of setup problem on my openSuse install, but I have no idea where to start looking to fix this.
Cheers,
Craig
It appears that /usr/lib64/libQtGui.so have hardcoded rpaths in them to locate dependent shared libraries. On one of your hosts the needed libraries are in the expected location while on the other host they are not.
You can use something like elfdump to get the RPATH out of the QT shared library to find out where it will look. Then you can use (I believe) -R on your link command line to point it to where the libraries are actually installed on that host.
EDIT: I think you can do something like objdump -x <binary/library> | grep -i rpath

error in compiling using cmake utility

I am trying to compile my gcc code using the following make command .
OS :Redhat ,gcc - 4.1
But I am getting error as follows :
rmtrain#lintrni130 $ /usr/local/bin/make all
[ 21%] Built target GCVCore
Linking CXX executable CFE
/usr/bin/ld: warning: libicui18n.so.36, needed by ../../Generic/icu/lib/libicuio.so, not found (try using -rpath or -rpath-link)
/usr/bin/ld: warning: libxalanMsg.so.110, needed by ../../Generic/Xalan/lib/libxalan-c.so, not found (try using -rpath or -rpath-link)
CMakeFiles/CFE.dir/trnuser1/rmtrain/DevelopmentEnv/Generic/ConvUI/GCVConvUISetting.o: In function `xercesc_2_6::XMLAttDefList::~XMLAttDefList()':
GCVConvUISetting.cpp:(.text._ZN11xercesc_2_613XMLAttDefListD0Ev[xercesc_2_6::XMLAttDefList::~XMLAttDefList()]+0x2f): undefined reference to `xercesc_2_6::XMemory::operator delete(void*)'
Please Help with this .
The warnings means that some libraries you link to have dependencies on other shared libraries, and those libraries weren't found in the linker's search path. The linker manual describes how it forms that search path in the docs for the -rpath-link option
They're only warnings, so haven't caused your link to fail. It will be a problem if those required libs aren't found at run-time, but is not necessarily a problem at link-time.
If you want to silence the warnings you will need to find out which directory contains libicui18n.so.36 and libxalanMsg.so.110 and use one of the methods described in the manual to tell the linker to look in that directory.
The last line is the real problem, and indicates you are not linking to the library which defines that symbol. You'll need to find out which library it is and link to it with -lfoo, it will probably be something like -lxerces
i reinstalled icu 3.2 instead of 3.6.It worked fine then.