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
Related
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.
I have a C++ project, and I am transitioning from Visual Studio Solutions to SCons for builds, so Linux users can also build my code. This is my first foray into SCons, and it's working very well with simple projects. But, for this project, I have a nested directory structure:
main/
sub1/*.cpp
sub2/*.cpp
sub3/*.cpp
file1.cpp
file2.cpp
And I have the following SConstruct file:
env = Environment()
env['PCHSTOP'] = 'stdafx.hpp'
env['PCH'] = env.PCH('stdafx.cpp')[0]
env.Program('program', [
'file1.cpp',
'file2.cpp',
'sub1/file1.cpp',
'sub2/file1.cpp',
'sub3/file1.cpp'
])
Running scons from the command line causes the following error:
fatal error C1083: Cannot open include file: 'stdafx.hpp': No such file or directory
Obviously, this is an MSVC error. But this should be solvable with Scons, I'm just not sure how..
I Noticed that Visual Studio will copy all the *.obj files to a build directory before linking by default. I think this may be part of the solution, but again, I'm unsure.
What I AM sure of, is this is not the first time someone has come across this problem, but Google didn't turn up anything for me.
PS: Unlike in the example, none of the files have naming conflicts, and could theoretically be moved to a flattened folder structure by SCons without issue.
This looks like you'll have to specify the proper include paths in your Environment via the "CPPPATH" variable...but it's difficult to tell without seeing the full command line. Remember, that all SCons envs are clean initially. So, if you're in the wrong working directory, a simple "#include " doesn't find the header if it's in a different folder.
Have a look at SCons' UserGuide, chap. 14 "Hierarchical Builds", which might give you a few more ideas and insights, or come over to the User mailing list at scons-users#scons.org.
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.
I need to build the log4cxx library on a SuSE linux system where I am not root. The package manager, zypper, apparently does not know about log4cxx.
I download log4cxx and try to build with autotools
./configure
checking for APR... no
configure: error: APR could not be located. Please use the --with-apr option.
I then search for libapr:
find / -name libapr*
/usr/share/doc/packages/libapr-util1
/usr/share/doc/packages/libapr1
/usr/lib64/libaprutil-1.so.0.3.12
/usr/lib64/libapr-1.so.0.4.5
/usr/lib64/libaprutil-1.so.0
/usr/lib64/libapr-1.so.0
So I try
./configure --with-apr=/usr/lib64/libapr-1.so.0
configure: error: the --with-apr parameter is incorrect. It must specify an install prefix, a build directory, or an apr-config file.
The same for --with-apr=/usr/lib64/libapr-1.so.0.4.5 and --with-apr=/usr/lib64/.
Which file does ./configure look for? What does --with-apr expect? Is one of the two *.so.* files the needed library?
You'll probably want to install libapr1-devel so that you can compile against it. Then try re-running ./configure.
I ran into the same issue, I think you're using the source code off of appache's site which I beleive is outdated. This issue has been fixed in the SVN trunk several years ago (lolol, I guess right around the time this question was asked).
Just pull the svn trunk's source and compile it:
svn checkout http://svn.apache.org/repos/asf/incubator/log4cxx/trunk apache-log4cxx
./autogen.sh
./configure
make
make check
sudo make install
On software.opensuse.org someone has packages built for recent versions of openSUSE as well as SLE at liblog4cxx10. Maybe that'll work for you instead of building your own.
MichaelGoren is right.
There is multiple ".h" file missing.
So you have to add them before launching make.
sed -i '1i#include <string.h>\n' src/main/cpp/inputstreamreader.cpp
sed -i '1i#include <string.h>\n' src/main/cpp/socketoutputstream.cpp
sed -i '1i#include <string.h>\n' src/examples/cpp/console.cpp
sed -i '1i#include <stdio.h>\n' src/examples/cpp/console.cpp
I bumped into the same problem on 3.3.4-5.fc17.x86_64 and resolved it by including the appropriate H files to the CPP files reported by the make utility.
In my case I should run the make utility 3 times each time getting a new error and fixing it by adding the appropriate include H to the reported CPP file.
The main idea is as following:
1) Check by running the man utility, where the function mentioned in the error defined.
For example, man memmove says that it is defined in the string.h header file.
2) Add the appropriate include file to the CPP file.
For example, the make utility complains that inputstreamreader.cpp does not find the memmove function. Open the inputstreamreader.cpp file and add string.h to its header files.
3) Run the make utility until the log4cxx is compiled without errors.
I'm trying to get up and running with Boost, so I'm trying to compile the simple example problem from Boost's "Getting Started" page. I've had two issues, and I'm not sure they're related (I'm better than a novice, but not by much) but maybe they're related...
1st issue: the "tar --bzip2 -xf /path/to/boost_1_49_0.tar.bz2" command didn't work (yes, I put the correct path in, but it gave me some errors, I forget what they were) so I used "tar -xjvf " from the directory where boost_1_49_0.tar.bz2 was located. That de-compressed the zip file and I proceeded with the example...
2nd issue: The example.cpp file will not compile, the first statement in the code is #include "boost/lambda/lambda.hpp" but then for every header file lambda.hpp is trying access, there's a "No such file or directory" compile error. For example, here are two (of the six, and I get errors for all 6) header files within lambda.hpp and the errors displayed by the cygwin compiler:
boost/lambda/lambda.hpp:14:33: boost/lambda/core.hpp: No such file or directory
boost/lambda/lambda.hpp:21:52: boost/lambda/detail/operator_actions.hpp: No such file or directory
If it helps, this is the command I'm running to compile (I generally create the executable in a separate -o command):
g++ -c example.cpp
Why can't the system find these? I added the installed directory (path/to/boost_1_49_0) to the PATH variable before I started so I know that's no it. Thanks for any advice...
(I've looked on stackoverflow and there were similar issues, but no solutions that worked)
It looks like you've already solved the first issue: namely, that you must specify the -j flag on tar to untar a bzip2'd file.
For the second issue, you need to specify boost on your include path, either by specifying it with the -I command line option or via the CPLUS_INCLUDE_PATH environment variable.