I'm learning the v4l2 API for configuring video devices through v4l2-ctl. The code samples from ages ago are really out of date and some of the defines don't work anymore. There is a new method of requesting everything for the API from the kerhel which is shown in v4l2-utils. I'm trying to incorporate some of the code from v4l2-utils into my code. However, I'm getting an error from the compiler:
camera.hpp:1038:8: error: 'struct v4l2_ext_controls' has no member named 'which'
ctrls.which = V4L2_CTRL_ID2WHICH(qctrl.id);
And:
camera.hpp:1038:43: error: 'V4L2_CTRL_ID2WHICH' was not declared in this scope
ctrls.which = V4L2_CTRL_ID2WHICH(qctrl.id);
The field and define are in a file located in the linux source tree: /usr/src/linux-4.6.3-gentoo/include/uapi/linux/videodev2.h, but that file is not included when I specify:
#include <linux/videodev2.h>
What is the voodoo to get the compiler to include the correct file?
I've been studying the v4l2-utils source but can't figure it out.
Thanks much.
The file located in /usr/include was out of date. I had the headers installed for kernel 4.3 and needed the ones from a later version. The solution for my gentoo install was to add a keyword for sys-kernel/linux-headers and install the latest headers (4.7).
It turns out that the UAPI file becomes the headers when installed into /usr/include. I could probably have accomplished this with make headers_install in my /usr/src/linux directory as well, but I'm not sure whether that is more "correct" than installing the linux-headers ebuild. I worry about conflicts.
Hope this helps someone else...
Related
I'm trying to get Flycheck to correctly see where OpenGL is on my Mac, but it can't seem to find it. I've tried adding the following lines to my .clang_complete file, but nothing seems to work. I keep getting the error OpenGL/gl.h could not be found:
-framework OpenGL
-I/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks/OpenGL.framework/Headers
This doesn't happen during compilation, it's just messing up static analysis and compilation by Irony. The directory I listed has gl.h and glu.h in it directly, which is probably why it didn't help to add, but I can't figure out how to get Irony to see the files correctly.
Edit: Using Flycheck for syntax checking, not Irony
Edit: macOS X Framework directory:
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks/
OpenGL.framework/
Headers/
Modules/
OpenGL.tbd/
Versions/
Well, since no one seems to have an answer on this, I'll post my workaround. By symlinking /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks/OpenGL.framework/Headers to /usr/local/include/OpenGL, you can give the checker the file path it wants, fixing the issue. Not the best solution, but a decent workaround nonetheless.
I'm developing a prototype using ARM's mbed OS. I'm newish to C++ so having syntastic working would be ideal, but it gets hung up on the import of "mbed.h".
The structure of the project is:
/
myfile.cpp
mbed-os/
mbed.h
Syntastic is saying fatal error: 'mbed.h' file not found.
How can I get Syntastic / GCC (or whatever it's using) to find the header files?
UPDATE:
Looks like including a .syntastic_cpp_config file with the following in is helping (but involved an absurdly painful process of add a line, run Syntastic, find the next missing header file):
-Imbed-os
-Imbed-os/cmsis
-Imbed-os/cmsis/TARGET_CORTEX_M
-Imbed-os/cmsis/TARGET_CORTEX_M/TOOLCHAIN_GCC
-Imbed-os/drivers
-Imbed-os/events
-Imbed-os/features
-Imbed-os/hal
-Imbed-os/platform
-Imbed-os/rtos
-Imbed-os/targets
-Imbed-os/targets/TARGET_NORDIC/TARGET_NRF5
-Imbed-os/targets/TARGET_NORDIC/TARGET_NRF5/TARGET_MCU_NRF52832
-Imbed-os/targets/TARGET_NORDIC/TARGET_NRF5/TARGET_MCU_NRF52832/TARGET_NRF52_DK
-Imbed-os/targets/TARGET_NORDIC/TARGET_NRF5/TARGET_MCU_NRF52832/device
-Imbed-os/targets/TARGET_NORDIC/TARGET_NRF5/TARGET_SDK11/device
-Imbed-os/tools
This isn't a complete list at all, but I'd almost rather just hit compiler errors at this state and work with those rather than continue hunting for header files.
You can get an exhaustive list of flags by generating the Makefile of your project with :
mbed export -i make_gcc_arm -m K64F --profile mbed-os/tools/profiles/debug.json
cf: https://os.mbed.com/docs/v5.6/tools/debugging.html
I'm trying to use tensorflow as a external library in my C++ application (mainly following this tutorial). What I done so far:
I have cloned the tensorflow reporitory (let's say, that the repo root dir is $TENSORFLOW)
Run /.configure (which all settings default, so no CUDA, no OpenCL etc.).
Build shared library with bazel build -c /opt //tensorflow:libtensorflow_cc.so (build completed successfully)
Now I'm trying to #include "tensorflow/core/public/session.h". But after including it (and adding $TENSORFLOW and $TENSORFLOW/bazel-genfiles to include path), I'm receiving error:
$TENSORFLOW/tensorflow/third_party/eigen3/unsupported/Eigen/CXX11/Tensor:1:42:
fatal error: unsupported/Eigen/CXX11/Tensor: No such file or directory
There is a github issue created for similar problem, but it's marked as closed without any solution provided. Also I tried with master branch as well as v.1.4.0 release.
Do you happen to know, what could cause this kind of problem and how to deal with it?
I (and many others) agonized over the same problem. It probably can be solved using bazel but I don't know that tool well enough and now I solve this using make. The source of confusion is that a file named Tensor is included and it itself includes a file named Tensor, which has caused some people to wrongly conclude Tensor is including itself.
If you built and installed the python .whl file there will be a tensorflow directory in dist-packages and an include directory below that, e.g. on my system:
/usr/local/lib/python2.7/dist-packages/tensorflow/include
From the include directory
find . -type f -name 'Tensor' -print
./third_party/eigen3/unsupported/Eigen/CXX11/Tensor
./external/eigen_archive/unsupported/Eigen/CXX11/Tensor
The first one has
#include "unsupported/Eigen/CXX11/Tensor"
and the file that should satisfy this is the second one.
So to compile session.cc that includes session.h, the following will work
INC_TENS1=/usr/local/lib/python2.7/dist-packages/tensorflow/include/
INC_TENS2=${INC_TENS1}external/eigen_archive/
gcc -c -std=c++11 -I $INC_TENS1 -I $INC_TENS2 session.cc
I've seen claims that you must build apps from the tensorflow tree and you must use bazel. However, I believe all the header files you need are in dist-packages/tensorflow/include and at least for starters you can construct makefile or cmake projects.
Slightly off-topic, but I had the same error with a C++ project using opencv-4.5.5 and compiled with Visual Studio (no problem with opencv-4.3.0, and no problem with MinGW).
To make it work, I had to add to my root CMakeLists.txt:
add_definitions(-DOPENCV_DISABLE_EIGEN_TENSOR_SUPPORT)
If that can help someone...
the problem was actually in the relative path of the header file taken in the Tensor file.
installed path for Tensor is /usr/include/eigen3/unsupported/Eigen/CXX11/Tensor
but mentioned in the Tensor file is "unsupported/Eigen/CXX11/Tensor"
So there should be an entry upto /usr/include/eigen3/ in the project path to run this correctly so that it can be used.
https://github.com/vikram-ma/OCR
when I try to run main.cpp from this code i got the following error
In file included from /home/akash/Desktop/OCR-master/main.cpp:9:0:
/home/akash/Desktop/OCR-master/OCR.h:43:3: error: ‘CvKNearest’ does not name a type
CvKNearest *knn;
^
CMakeFiles/OCR.dir/build.make:62: recipe for target 'CMakeFiles/OCR.dir/main.o' failed
please help
At first glance it seems you don't have OpenCV installed/downloaded.
The code you are poining to uses OpenCV library and it assumes you already have it.
You should go to OpenCV releases and download the version you need.
Edit:
I looked into it more closely and as suspected the code was using an old OpencCV version. Right now you are using 3.2.0 so you need to make some updates to the code itself.
Either you should go with an older version of the library (which I'm not suggesting but will be probably less effort) like 2.3-2.4 or update the code to the version you've already installed.
If you wish to do the latter, you can start by looking here: Transition guide
Among others, it is shown there that what used to be CvKNearest is now moved to cv::ml::KNearest. Updating accordingly should fix your first error.
Very recently, I had this idea to start using Mozilla NSS and to learn to use it, so that somewhere in the future, i can use it, or can atleast start contributing to it.
So i went to its Website and cloned it source code into a director "NSS" using mercurial
Then I used
make nss_build_all
instead of
gmake nss_build_all
Note : I don't know, if it makes a difference, gmake is just GNU Make
This make command created a dist folder outside the nss folder. So, Now my NSS folder has 3 folders nss,nspr,dist.
In .bashrc i added a line at the end
export LD_LIBRARY_PATH=/home/ayusun/workspace/NSS/dist/Linux3.5_x86_glibc_PTH_DBG.OBJ/lib
Then i went over to this Sample code, did a copy paste and saved it in my NSS Folder.
And then i tried to compile it, but it failed, stating it couldn't find iostream.h, I went over and changed the location of header files
So
<iostream.h> became <iostream>
"pk11pub.h" became "nss/lib/pk11wrap/pk11pub.h"
"keyhi.h" became "nss/lib/cryptohi/keyhi.h"
"nss.h" became "nss/lib/nss/nss.h"
I tried compiling again but this time error came, that it couldn't find "planera.h"
which is actually present in dist/*.OBJ/include/ which is a link to a file planeras.h in nspr
And so i don't know, how to include these files anymore.
I always have trouble when it comes to include 3rd party header files.
Thanks
This is an old question, but I'll answer it anyway for future reference.
The simplest way is just to use the NSS package for your operating system.
Then you can use things like nss-config --cflags, nss-config --libs, nspr-config --cflags and nspr-config --libs and add that to your CFLAGS and LDFLAGS as appropriate.
For those who do decide to compile their own NSS, I'll give the quick overview.
The NSS headers are in dist/public. Add -I/path/to/dist/public to your compiler command line. The NSPR headers are in dist/Debug/include¹ so add -I/path/to/dist/Debug/include to your comiler command line.
Now you can use #include <nspr/prio.h> and #include <nss/nss.h> and friends.
The NSS code relies on directly uncluding the NSPR headers, so you'll need to add -I/path/to/dist/Debug/include/nspr for it to find things like plarena.h. Or you could do the same and not prefix your includes like I did above. It's up to you.
Now add -L/path/to/dist/Debug/lib and -lnss3 -lnspr4 to your linker command line. You may want to also add -rpath /path/to/dist/Debug/lib for the runtime link path, or copy them to a system directory or use LD_LIBRARY_PATH.
I hope this gets you started.
¹ This actually depends on your operating system and build type. I hope you can figure out the name of the actual Debug directory in your case.