Since I am using IDE instead of GNU writing codes, I am having a hard time reading those documents about Makefile, so far I couldn't find any documents states clearly where to put $BOOST_HOME. (I am using Boost Library for my project so it needs to compile with it)
so far I am compiling the program with this command:
g++ -Wall -std=c++11 -o ladder Source1.cpp -I/home/s/suw/boost_1_65_1
since this will be compile in other's computer so the path of boost library will be different thus I need to put $BOOST_HOME into Makefile, any help would be appreciated.
EDIT:
So I think I need to set $BOOST_HOME a path and put it into makefile, but path is varies by different user, how to let somebody run my program by just using a simple:
g++ *.cpp -o foo
???
Related
I want to set up GLFW3 to work with C++ in a program called 4coder. I have a folder named libraries that holds all the stuff I need, I just don't know how to get C++ to include them using #include <GLFW/glfw3.h>. I literally started using C++ today and have no idea where to start.
You will need to add arguments when compiling the source code to specify the location of your headers and libraries. Exactly how this is done will depend on which compiler you are using but for example if you're using g++:
path-to-working directory>g++ name-of-file.cpp -Ipath-to-header-files -Lpath-to-library-files -lglfw3 -o name-of-executable
The key points here are the -I flag (which tells the compiler where to look for header files) and the -L flag (which tells the compiler where to look for libraries). -lglfw3 will then cause the compiler to look in the directory specified with the -L flag for the glfw3 library.
If you're using a different compiler, the syntax may be different but the general principle will apply - you just have to find the equivalent commands to -I and -L.
I can't make gcc compiler recognize complex paths in "includes".
Here's my toy "main.cpp" file (note the sub-directory in the include statement):
#include "sub/testlib.h"
int main()
{
testlib(6);
return 0;
}
Here's the path to the file "testlib.h" from the folder "main.cpp" lives in: ../lib/sub/testlib.h.
I'm specifying the include directory while compiling:
gcc -c -iquote../lib main.cpp
And the compiler yells at me:
main.cpp:1:10: fatal error: sub/testlib.h: No such file or directory
1 | #include "sub/testlib.h"
| ^~~~~~~~~~~~~~~
compilation terminated.
Of course I can make it compile by removing sub-directory from the path. But this is just an experiment I make after having failed to compile a real-world project. I can't freely change the files there.
How do I force gcc to treat sub-directories well in the includes? Is there a flag or some option that I'm missing here?
How do I force gcc to treat sub-directories well in the includes? Is there a flag or some option that I'm missing here?
Read the documentation of GCC, in particular the Invoking GCC chapter, the section on preprocessor options (e.g. -I include-dir or -H or -M, etc...), the documentation of the preprocessor. Try also g++ --help ; the -I include-directory flag can be repeated a lot of times and is probably what you need. Of course, order of arguments to the g++ program matters a lot. You probably want to use g++ not gcc when compiling or linking C++ programs.
Read also some documentation of C++ (maybe even the n3337 "draft" standard). Be aware of translation units, and of the role of the linker.
In practice, you want to drive GCC compilation using some build automation tool, such as GNU make or ninja or many others.
If you use GNU make, read its documentation then try make -p which shows the many built-in rules known to that software. Be aware of the many functions of make.
If you use ninja, read its documentation, you probably want to generate the build.ninja script it is using. You could generate it using a Python script or a Guile one (or your own C++ program, etc...).
Be aware that of course g++ will invoke some GNU binutils utilities (e.g. the assembler as or the linker ld).
Practically speaking, invoke g++ as g++ -Wall -Wextra -g to get warnings and debug information (of course with additional -I include-directory flags). Then use the gdb debugger. Once your program has few bugs, add optimization flags such as -O2
See also Clang, its static analyzer, Frama-C, and CompCert and, at end of 2020, Bismon.
Consider in some cases to generate some #include-d C++ code (e.g. with SWIG or ANTLR or Qt or your own script) or to extend GCC with your plugins.
Be of course aware of the Joel Test.
I have an already built library made of this files:
A bunch of headers.
A .so file (libmylib.so).
I want to compile a c++ program (sample.cpp), where I included the headers, and where I need to use the library. This is what I've done, and it's working:
Put the headers in usr/local/include.
Put the .so file in usr/local/lib.
Compile the program in this way: g++ sample.cpp -lmylib.
My question is: why is it not working if I omit -lmylib from the last line?
Is there a way to install the library such that I don't need to put it every time in the g++ command?
Thank you.
What libs are used by default depends on some setting in the compiler/linker,
but it´s not "every lib in usr/local/lib" or any directory, just some specific names
(or even just a single one). Call g++ -v or g++ -dumpspecs to list it (and more stuff)
So, either rebuild your compiler with your own lib list, or specify it manually everytime.
I'm using g++ on linux and writing multiple cpp programs. For ex. I have ex1.cpp, ex2.cpp, bot.cpp.
All these cpp programs are inside the same folder. I want to use make to compile individual programs as in "make ex1" should compile ex1.cpp and not the other cpp files. "make bot" should only compile bot.cpp
The compilation command I intend to execute is :
g++ -o bot bot.cpp
I don't want to write target and dependency in MakeFile for every cpp program I create in the folder and I don't want to compile all cpp's at one go using *.cpp.
Is it possible first of all to achieve this ? Is yes please suggest a solution
A simple solution to your question :
Just run make ex1 in the command line and it will compile using the command g++ ex1.cpp -o ex1.
If you want to dynamically include libraries/shared objects or add additional flags then you should create a make file or follow the procedure suggested by Lukasz (Too complicated though).
You don't need to write a makefile. make ex1 should already do what you want.
This problem is not specific to Fubi, but a general linker issue. These past few days (read as 5) have been full of linking errors, but I've managed to narrow it down to just a handful.
I'm trying to compile Fubi (Full Body Interaction framework) under the Linux environment. It has only been tested on Windows 7, and the web is lacking resources for compiling on a *nix platform.
Now, like I mentioned above, I had a plethora of linking problems that dealt mostly with incorrect g++ flags. Fubi requires OpenNI and NITE ( as well as OpenCV, if you want ) in order to provide it's basic functionality. I've been able to successfully compile both samples from the OpenNI and NITE frameworks.
As far as I understand, Fubi is a framework, thus I would need to compile a shared library and not a binary file.
When I try to compile it as a binary file using the following command
g++ *.cpp -lglut -lGL -lGLU -lOpenNI -lXnVNite_1_5_2 -I/usr/include/nite -I/usr/include/ni -I/usr/include/GL -I./GestureRecognizer/ -o FubiBin
and I get the output located here. (It's kind of long and I did not want to ruin the format)
If I instead compile into object files (-c flag), no errors appear and it builds the object files successfully. Note, I'm using the following command:
g++ -c *.cpp -lglut -lGL -lGLU -lOpenNI -lXnVNite_1_5_2 -I/usr/include/nite -I/usr/include/ni -I/usr/include/GL -I./GestureRecognizer/
I then am able to use the ar command to generate a statically linked library. No error [probably] occurs (this is only a guess on my end) because it has not run through the linker yet, so those errors won't appear.
Thanks for being patient and reading all of that. Finally, question time:
1) Is the first error regarding the undefined reference to main normal when trying to compile to a binary file? I searched all of the files within that folder and not a single main function exists.
2) The rest of the undefined reference errors complain that they cannot find the functions mentioned. All of these functions are located in .cpp and .h files in the subdirectory GestureRecognizer/ which is a subdirectory of the path I'm compiling in. So wouldn't the parameter -I./GestureRecognizer/ take care of this issue?
I want to be sure that when I do create the shared library that I won't have any linking issues during run-time. Would all of these errors disappear when trying to compile to a binary file if they were initially linked properly?
You are telling the compiler to create an executable in the first invocation and an executable needs a main() function, which it can't find. So no, the error is not normal. In order to create a shared library, use GCC's "-shared" option for that. Trying some test code here, on my system it also wants "-fPIC" when compiling, but that might differ. Best idea is to dissect the compiler and linker command lines of a few other libraries that build correctly on your system.
In order to add the missing symbols from the subdirs, you have to compile those, too: g++ *.cpp ./GestureRecognizer/*.cpp .... The "-I..." only tells the compiler where to search when it finds an #include .... I wouldn't be surprised if this wasn't even necessary, many projects use #include "GestureRecognizer/Foo.h" to achieve that directly.
BTW:
Consider activating warnings when running the compiler ("-W...").
You can split between compiling ("-c") and linking. In both cases, use "g++" though. This should decrease your turnaround time when testing different linker settings.