The wrong message was that cannot open the opencv lib.However,I had made the opencv lib.The lib file is 11_camera_object_identification/opencv_consumer_lib/libopencv_consumer.so
If the linker cannot find the library in its path, then you’d have to make custom runtime loading changes. To see what your linker sees:
ldconfig -p
To check for “libopencv” you might run:
ldconfig -p | grep -i opencv
Note that in some cases after adding a library within the linker’s standard path that you would either need to reboot or run “sudo ldconfig” to refresh the listings. See “man ldconfig” and “man ld.so” for more information. A typical standard search path setup is via “/etc/ld.so.conf”, which in turn often divides listings from files in “/etc/ld.so.conf.d”. To see what is already searched:
cat /etc/ld.so.conf /etc/ld.so.conf.d/*
I did as what you told me,but cannot slove the problem.The wrong messages as follows:
root@tegra-ubuntu:/home/ubuntu/tegra_multimedia_api/samples/11_camera_object_identification# ./camera_caffe -width 1280 -height 720 -lib opencv_consumer_lib/libopencv_consumer.so -model /home/caffe/models/bvlc_reference_caffenet/deploy.prototxt -trained /home/caffe/models/bvlc_reference_caffenet/bvlc_reference_caffenet.caffemodel -mean /home/caffe/data/ilsvrc12/imagenet_mean.binaryproto -label /home/caffe/data/ilsvrc12/synset_words.txt
Fail to open OPENCV LIB, continue to run without processing
NvPclHwGetModuleData: Misc Driver v4l2_focuser_stub already exists. Avoiding duplicate drivers
Sensor_LoadModeModeType: mode 0: Failed to load pixeltype
Sensor_LoadModePixelPhase: mode 0: Failed to load pixeltype
Sensor_LoadModeModeType: mode 1: Failed to load pixeltype
Sensor_LoadModePixelPhase: mode 1: Failed to load pixeltype
Sensor_LoadModeModeType: mode 2: Failed to load pixeltype
Sensor_LoadModePixelPhase: mode 2: Failed to load pixeltype
PRODUCER: Creating output stream
PRODUCER: Launching consumer thread
Failed to query video capabilities: Bad address
libv4l2_nvvidconv (0):(765) (INFO) : Allocating (10) OUTPUT PLANE BUFFERS Layout=1
libv4l2_nvvidconv (0):(775) (INFO) : Allocating (10) CAPTURE PLANE BUFFERS Layout=0
create vidoe converter return true
CONSUMER: Waiting until producer is connected…
PRODUCER: Starting repeat capture requests.
CONSUMER: Producer has connected; continuing.
Sensor_GetV4LPixelType: pixel type 0x101 invalid
CONSUMER: acquireFd 1828717896 (1 frames)
CONSUMER: acquireFd 1828717897 (2 frames)
CONSUMER: releaseFd 1828717896 (2 frames)
CONSUMER: releaseFd 1828717897 (1 frames)
CONSUMER: acquireFd 1828717897 (1 frames)
CONSUMER: releaseFd 1828717897 (1 frames)
CONSUMER: acquireFd 1828717898 (1 frames)
CONSUMER: releaseFd 1828717898 (1 frames)
CONSUMER: acquireFd 1828717898 (1 frames)
Could anyone help me? Thanks a lot!
The problem is that the library needed is not where the linker can find it. The “ldconfig -p” is to show what the linker is able to find…“ldconfig -p | grep opencv” will show what opencv files it sees…to get what you want this must answer with the lib the attempt to run fails to find. Moving the library into the linker path and either rebooting or using ldconfig to update would make it available. The commands are basically to demonstrate what the linker sees…if you don’t manually put that lib in the right place it will always fail.
NOTE: Choice 1 is to put the library where it is searched for…not where it is. Choice 2 is to put that location in the linker path…a risky thing to do if it isn’t a system path.
I got the lib file libopencv_consumer.so into the /usr/lib and ldconfig,but “Fail to open OPENCV LIB, continue to run without processing” still appears.
First of all,my building of caffe was OK,and I tried on two TX1 boards,the errors are same!
I want to konw if the example program runs ok on your TX1 board!!
Solved the problem.
After building caffe,I forgot to get the caffe libs into the /usr/lib or ln the lib.So the function dlopen() cannot open the lib opencv_consumer.so.When I used the function dlerror(),I got the reason.
Thank you, linuxdev.
Testing out this sample for the first time today, I came across the same issue. Doing export LD_LIBRARY_PATH=$HOME/Work/caffe/caffe-master/build/lib:/usr/local/cuda/lib64 did not fix the issue. Did you go into /CAFFE_ROOT/build/lib and link all of the libraries into /usr/lib ?
Confirmed that a copy out of /build/lib into /usr/lib fixes the crash. I imagine sudo ln -s CAFFE_ROOT/build/lib/* /usr/lib/ I’ll close this topic, though if someone thinks of a more elegant solution, please suggest it below.
I think the method of manually linking is actually the correct thing to do…though tradition would be that if the files are not part of the dpkg installed system you’d use somewhere like “/usr/local/lib/”, and add that to the system’s linker path (separate hand edited parts of the system from standardized parts). It is possible something else already adds “/usr/local/lib” to the linker path, YMMV.
If you go to “/etc/ld.so.conf.d/” you’ll see it’s arranged so that you can add a location without editing everything else. You might add a file like “/etc/ld.so.conf.d/caffe.conf” and content:
/usr/local/lib
You won’t see immediate visibility without either rebooting or telling the linker to manually refresh:
sudo ldconfig
Once that is done you can list what the linker sees and grep for the library to verify it is found (“ldconfig -p | grep -i ‘somelib’”).
Beware though that if you put something bad in the system linker path you could end up needing to rescue the system…it’s for libraries you know work, not for experiments (the LD_LIBRARY_PATH is for experiments).