I'm developing a clang based tool with which I process the AST generated by clang. Right now I'm developing inside the llvm-project tree (I cloned the whole repository) as mentioned in this tutorial. I've created the CMakeLists.txt as mentioned and I executed the cmake command as seen in the tutorial.
The project compiles and the output binary file is located in the build/bin with the other binaries inside the llvm-project source tree. When I execute my binary from the build/bin, upon parsing the input c++ file, everything goes well.
But, when I copy the generated binary to my home directory or anywhere else and I execute it, upon the parsing, it does not manage to find the standard headers for instance stddef.h:
/usr/include/stdlib.h:32:10: fatal error: 'stddef.h' file not found
My question is why it can find the header in one place and not in another? In one of the forum I found this: Some header files (stddef.h, stdarg.h, and others) are shipped with Clang — these are called builtin includes. Clang searches for them in a directory relative to the location of the clang binary.
I've checked the build directory, in which the binary is located originally, and it contains lib/clang/include directory in which there is also the file stddef.h. Is it possible that by executing in place the binary, it founds this path and when I copy it somewhere else it does not find the right path?
EDIT:
The command I execute is:
build/bin/mytool source.cpp -- -I(list of headers without system headers)
Related
I have a project which im working in with C++20 in Eclise IDE, I'm using CygWin 3.4.0-1 compiler. I edited my source lookup path for my main file as gdb had the wrong route, now i can see the main file while debugging, but it won't find the source file for any other included file that is not the main.
This is one of the errors i get:
Can't find a source file at "/usr/lib/gcc/x86_64-pc-cygwin/11/include/c++/x86_64-pc-cygwin/bits/Pin.hpp"
If I locate the file with the actual Pin.hpp, the debugger will show it to me but the instructions it's running make no sense when going step by step.
This is my source lookup path configuration:
I'm trying to build qt project but I keep getting error about no existing header in moc object moc_SerialPortManager.cpp. I moved with bash to that directory and used cd cmd with the path written in mock object and it leads to the correct directory. Does anybody have a slightest idea how to resolve it? At this point it's quite big project so just please tell me what could I publish to make this easier for you?
I have it all on git https://github.com/Orpiczy/AcornScanner/compare/fronAndBackJoin if you wish to check it out
I'm using Mingw compiler 8.1.0 64-bit for c++ and Qt 6.2.0, I'm working on windows10
moc_SerialPortManager.cpp
#include <memory>
#include "../../../../../../source/controllers/LowLevelFunctionality/DeviceController/ProfilometerManager/SerialPortManager.hpp"
#include <QtCore/qbytearray.h> ...
logs
E:\Dokumenty\AiR_rok_4\S7\EngineeringThesis\AcornScanner\cm\cm-lib\build\windows\gcc\x64\debug.moc\moc_SerialPortManager.cpp:10: error: ../../../../../../source/controllers/LowLevelFunctionality/DeviceController/ProfilometerManager/SerialPortManager.hpp: No such file or directory
........\AcornScanner\cm\cm-lib\build\windows\gcc\x64\debug.moc\moc_SerialPortManager.cpp:10:10: fatal error: ../../../../../../source/controllers/LowLevelFunctionality/DeviceController/ProfilometerManager/SerialPortManager.hpp: No such file or directory
#include "../../../../../../source/controllers/LowLevelFunctionality/DeviceController/ProfilometerManager/SerialPortManager.hpp"
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Note that the layout of your repository differs from your local filesystem:
.../debug/.moc/
vs.
.../debug.moc/
Therefore the relative path steps up one level too much and results in a non-existing path.
It is generally considered bad practice to put automatically generated files (i.e. moc files) under version control. I would assume if you remove the whole build directory and build again you will be fine.
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'm writing a large OCaml project. I wrote a file foo.ml, which works perfectly. In a subdirectory of foo.ml's directory, there is a file bar.ml.
bar.ml references code in foo.ml, so its opening line is:
open Foo
This gives me an error at compile time:
Unbound module Foo.
What can I do to fix this without changing the location of foo.ml?
The easy path is to use one of OCaml build system like ocamlbuild or oasis. Another option would be jbuilder but jbuilder is quite opiniated about file organization and does not allow for the kind of subdirectory structure that you are asking for.
The more explicit path comes with a warning: OCaml build process is complicated with many moving parts that can be hard to deal with.
After this customary warning, when looking for modules, OCaml compiler first looks for module in the current compilation environment, then looks for compiled interface ".cmi" files in the directories specified by the "-I" option flags (plus the current directory and the standard library directory).
Thus in order to compile your bar.ml file, you will need to add the parent directory in the list of included directories with the -I .. option.
After all this, you will discover that during the linking phase, all object files (i.e. .cmo or .cmx) need to be listed in a topological order compatible with the dependency graph of your project.
Consequently, let me repeat my advice: use a proper build system.
I'm quite confused about this weird behaviour of my .cpp project. I've got the following folder structure:
include/mylib.h
myproject/src/eval.cpp
myproject/data/file.csv
myproject/Makefile
In eval.cpp I include mylib.h as follows:
#include "../../include/mylib.h"
and compile it through Makefile:
all:
g++ -I include ../include/mylib.h src/eval.cpp -o eval.out
Now in my eval.cpp I'm reading the file.csv from data directory and if I refer to it like this
../data/file.csv
it doesn't find it (gets empty lines all the time), but this
data/file.csv
works fine.
So, to include mylib.h it goes two directories up (from src folder) which seems right. But it doesn't make sense to me that to refer to another file from the same piece of code it assumes we are in project directory. I suppose it is connected with Makefile somehow, but I'm not sure.
Why is it so?
EDIT: After a few thing I tried it seems that the path which is used is not the path from binary location to the data location, but depends on where from I run the binary as well. I.e., if I have binary in bin directory and run it like:
./bin/eval.out
It works with data/file.csv.
This:
cd bin
./eval.out
works with ../data/file.csv.
Now it seems very confusing to me as depending on where I run the program from it will give different output. Can anyone please elaborate on the reasons for this behaviour and if it is normal or I'm making some mistake?
It is so because (as explained here ) the compiler will search for #included files with quotes (not with brackets) with the current working directory being the location of the source file.
Then, when you try to open your .csv file, it's now your program that looks for a file. But your program runs with the current working directory being myproject/ which explains why you must specify data/file.csv as your file path, and not ../data/file.csv. Your program does not run in your src folder, it will run in the directory the binary ends up being invoked from.
You could have noticed that in your Makefile, your -I options specify a different path for your header file than your .cpp file.
EDIT Answer: It's quite simple actually and completely normal. When you invoke your binary, the directory which you're in is the current working directory. That is, if you run it with the command ./myproject/bin/eval.out, the current working directory is . (e.g. /home/the_user/cpp_projects). My post was a bit misleading about that, I corrected it.
Note: You can use the command pwd in a command prompt to know which is the current working directory of this prompt (pwd stands for "print working directory").