I'm using some methods from the c++ AlgLib library. In other libraries I've used there were some instructions for installation, after which I could include .h files and compile with -l (e.g. using the GMP-library and compiling with -lgmp). However with alglib the only thing I've been able to get running is using a makefile and compiling all needed .cpp files - every time I compile my program. Here is an example of a makefile:
all:
g++ name.cpp ap.cpp integration.cpp interpolation.cpp alglibinternal.cpp linalg.cpp
alglibmisc.cpp specialfunctions.cpp solvers.cpp optimization.cpp -o name
As compiling all these files every time is relatively time consuming, is there a way to avoid it?
You can use the make feature.
Make is a tool which controls the generation of executables and other non-source files of a program from the program's source files.
View the page: http://www.gnu.org/software/make/ to use this tool.
Related
I'm doing the "Hello World" in the GTKMM tutorial, the "app" uses three files, the main.cc, helloworld.h and helloworld.cc.
At the beginning I thought that compiling the main.cc :
g++ -o HW main.cc $(pkg-config ... )
would be enough, but gives an error (undefined reference to Helloworld::Helloworld), etc.
In other words, it compiles the main and the header, but not the HW class, and this makes sense because the header is included in Main but not the Helloworld.cc. The thing is I'm kinda scared of including it because I read in other question that "including everything was a bad practice".
That being said, when I compile using all the files in the same command:
g++ -o HW main.cc helloworld.cc $(pkg-config ... )
the "app" works without errors.
So, since using the last command works, is compiling in this way a good practice?
What happens if my app uses a big ton of classes?
Must I manually write them all down in the command?
If not, must I use #include?
Is it good practice using #include for all cc used files?
Is normal to list all the cpp/cc files when compiling with g++?
Yes, completely.
How else will it know what source code you want it to compile?
The thing is I'm kinda scared of including it because I read in other question that including everything was a bad practice.
#includeing excess headers is bad practice.
Passing your complete source code to the compiler is not.
Is it good practice using #include for all cc used files?
Absolutely not.
What happens if my app uses a big ton of classes? Must I manually write them all down in the command?
No. You should be using a build system that handles this for you. That could be an IDE which takes all the files in your project and passes them to the compiler in turn, or it could be a CMakeLists.txt/Makefile with a *.cpp wildcard in (although I actually recommend listing source files explicitly, one-by-one; it's not hard).
Invoking g++ manually on the command-line is fine for a quick test, but for real usage you don't want to be clowning around with such machinery.
is good practice using #include for all cc used files
It's not only bad practice, never do it.
In order to create an executable you actually have to do two things:
Compile all the source code files to object files or libraries.
Link all the object files and needed libraries into an executable.
You seem to be missing the point that the link phase is where symbols defined in separate source files are resolved or linked.
Must I manually write them all down in the command?
For the compiler to know about the DEFINTION of the symbols DECLARED in your headers, you must include all source files. Exceptions to this rule can be (but are not limited to) headers containing template metaprogramming (TMP) code that usually exist entirely in header files.
What happens if my app uses a big ton of classes?
Most of the large C++ projects utilize build configuration tools such as CMAKE to handle the generation of makefiles for them.
I am using gcov for the first time to analyze my program (C++)
The program consists of three classes and I have built the project using Code::Blocks.
When I am invoking the program using the following command:
C:\Users\XXX\Documents\Test\TreeObjModel\src>gcc
-fprofile-arcs -ftest-coverage Tree.cpp
I receive the following error:
Tree.cpp:1:18: fatal error: Tree.h: No such file or directory
compilation terminated
While the cpp files are in the directory "C:\Users\XXX\Documents\Test\TreeObjModel\src\" , the header files are in directory "C:\Users\XXX\Documents\Test\TreeObjModel\include\"
Do we need to have both the code and header files in the same directory?
Thanks in advance.
You should use the -I flag to specify where your header files are.
Judging from your example, you should add -I../include
You have at least two options to instruct the compiler where to find the header files (includes).
-Ipath_to_includes as parameter for gcc compiler. E.g. -I../include
When including in your program, specify the directory. E.g. #include "../include/foo.h"
My strategy would be to just compile my project successfully and only then try to use some other stuff, like flags for code coverage. I say this because your error does not have anything to do with gcov, and trying to instrument your program to get code coverage before your program even compiles, makes things more complicated for you. One step at a time ;)
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.