I'm trying to distribute a little software written on C++ on Linux that uses openGL and SFML. I'm trying to provide the sfml libraries and headers with my code in order to avoid the installation of sfml (people who will use it have no root access, but they will have all the openGL needed stuff installed).
My file hierarchy is as follows:
lib/ >> here goes all the sfml libraries (.so files)
Makefile >> later I show the code
src/ >> Here goes program and sfml sources
myfiles.h, myfiles.cpp >> all them compile and work allright with the sfml libraries installed at /usr/lib
SFML/ >> here goes all the sfml headers, has some subfolders
Here's my Makefile:
EJECUTABLE = app
MODULOS = src/main.o src/Handbapp.o src/Camera.o src/Light.o src/Scene.o src/Graphics.o src/Window.o src/Model.o src/Court.o src/Player.o src/Primitives.o src/Path.o
CC = g++
LIBDIR = ./lib
INCDIR = ./src
LIBS = -lsfml-window -lsfml-system -lGLU
LDFLAGS = -L$(LIBDIR) -I$(INCDIR)
CFLAGS = -v -Wl,-rpath,$(LIBDIR)
$(EJECUTABLE): clean $(MODULOS)
$(CC) $(CFLAGS) -o $(EJECUTABLE) $(LDFLAGS) $(MODULOS) $(LIBS)
rm -f $(MODULOS)
clean:
rm -f $(MODULOS) $(EJECUTABLE)
When I run make in a PC (Ubuntu 11.10) with sfml installed in /usr/lib it all goes well, if I do in one that doesn't have it installed it says:
...
g++ -c -o src/main.o src/main.cpp
In file included from src/main.h:18:0,
from src/main.cpp:10:
src/Handbapp.h:17:44: fatal error: SFML/Window.hpp: File or directory doesn't exist
Compilation finished.
make: *** [src/main.o] Error 1
Here's a piece of code showing the include on Handbapp.h:
...
#ifndef HANDBAPP_H
#define HANDBAPP_H
// Espacio de nombres
using namespace std;
// Librerias
#include <GL/gl.h> // OpenGL
#include <GL/glu.h> // Utilidades OpenGL
#include <SFML/Window.hpp> // Ventanas SFML <- LINE 17
#include <SFML/System.hpp> // SFML
I've tried making #include "whatever/Window.hpp",changing src/SFML folder name for whatever and not using the -I option on the linker, but src/SFML/Window.hpp (and other sfml headers) have include lines like that #include < SFML/Window/Whatever.hpp >, so I need them to search at the path I specify.
Am I missing something? I guess it's an error with my Makefile, but I don't have so much experience with it...
Thanks in advance!
You need to put -I$(INCDIR) into CPPFLAGS, not LDFLAGS. Then it will be picked up by the built-in rule for compilation of individual object files.
You should also rename CFLAGS to CXXFLAGS and CC to CXX. CC and CFLAGS are for C source files, not C++ source files.
You should not have $(EJECUTABLE) depend on clean, and you should not execute rm -f $(MODULOS) after the link command. Those things defeat the purpose of a Makefile, which is to recompile only what is necessary, not the whole program every single time.
The problem isn't in the compiler but in your Makefile: you want to set up the include directory path in the appropriate flags (I typically use CPPFLAGS but I typically also have my own rules which explicitly reference the flags I'm using). The LDFLAGS are definitely only passed to the linking stage of the build.
Related
Im trying to compile a C++ project using MinGW and can compile a simple main.cpp file with hello world without problems using g++ main.cpp -o main and also with external libraries using main.cpp extlib.cpp -o main.
But say im working on a rather large project with 10s of .cpp files organised inside of different files, how can I get the compiler to find all the cpp files that are needed? I know i can use main.cpp libs/*.cpp -o main but this will only compile all the source files inside of libs but not inside folders in libs.
Ive looked into make and cmake but dont understand how those automate the process if you still have to manually enter the directories. Is there no way to simply hit compile or at least a command line command to compile all the needed files inside a directory? This seems to work with #include without issues?
If you want to stick with MinGW and GNU Make I would probably use a Makefile that looks something like this to start with. You basically only need to maintain the srcs-variable by adding your source-files there. Usually you can use the wildcard-function for this if you have sub dirs. The rest of the Makefile (which can be left alone) sets up a build of an executable main.exe that depends on all the object-files. I also included dependency-handling via the deps-variable and the compiler flag -MMD which comes in handy when the project grows.
srcs := $(wildcard *.cpp) $(wildcard dir1/*.cpp) $(wildcard dir2/*.cpp)
objs := $(srcs:.cpp=.o)
deps := $(objs:.o=.d)
app := main.exe
CXXFLAGS := -MMD -Og -g -Wall -Werror -Wpedantic -std=c++2a
$(app): $(objs)
$(CXX) $(LDFLAGS) -o $# $^ $(LDLIBS)
-include $(deps)
.PHONY: clean
clean:
rm -f $(objs) $(deps)
I use CMake for simple projects.
Here's the simplest example I came with (CMakeLists.txt to put along your main.cpp in the root of your project):
cmake_minimum_required(VERSION 3.1)
SET(CMAKE_APP_NAME "Project")
project (${CMAKE_APP_NAME})
# list here your directories
INCLUDE_DIRECTORIES(dir1)
INCLUDE_DIRECTORIES(dir2)
# add an executable and list all files to compile
add_executable(${CMAKE_APP_NAME} main.cpp
dir1/file1.cpp
dir1/file1.h
dir2/file2.h
dir2/file2.cpp
)
Once your project becomes more complex, you could use file(GLOB*) to avoid writing all the files.
Overall, the most "automated" way to build a larger project is to use CMake. Keep learning it. You can use file(GLOB) to avoid listing every file in CMakeLists.txt. This is not recommended (see discussion here), but I do it anyway and never had any issues.
I am new to C++ and I am having trouble understanding how Makefiles do their thing with the g++ compiler.
I have successfully installed armadillo library (via apt) and have a very simple c++ program test.cpp, like the one below:
#include <iostream>
#include <armadillo>
using namespace std;
int main()
{
arma::mat A;
A << -1 << 2 << arma::endr
<< 3 << 5;
cout << A << endl;
arma::fmat B;
B.randu(4,5);
cout << B;
return 0;
}
This works just fine if I compile manually like this:
g++ src/test.cpp -std=c++11 -Wall -o test -DARMA_DONT_USE_WRAPPER -lopenblas -llapack
I can manually run the program and it delivers the matrices as expected.
On the other hand, I have the Makefile template from the VSCode C/C++ Extension, which I have modifed slightly for including the LAPACK an BLAS Fortran libraries:
########################################################################
####################### Makefile Template ##############################
########################################################################
# Compiler settings - Can be customized.
CC = g++
CXXFLAGS = -std=c++11 -Wall
LDFLAGS = -DARMA_DONT_USE_WRAPPER -lopenblas -llapack
# Makefile settings - Can be customized.
APPNAME = test
EXT = .cpp
SRCDIR = src
OBJDIR = obj
############## Do not change anything from here downwards! #############
SRC = $(wildcard $(SRCDIR)/*$(EXT))
OBJ = $(SRC:$(SRCDIR)/%$(EXT)=$(OBJDIR)/%.o)
DEP = $(OBJ:$(OBJDIR)/%.o=%.d)
# UNIX-based OS variables & settings
RM = rm
DELOBJ = $(OBJ)
# Windows OS variables & settings
DEL = del
EXE = .exe
WDELOBJ = $(SRC:$(SRCDIR)/%$(EXT)=$(OBJDIR)\\%.o)
########################################################################
####################### Targets beginning here #########################
########################################################################
all: $(APPNAME)
# Builds the app
$(APPNAME): $(OBJ)
$(CC) $(CXXFLAGS) -o $# $^ $(LDFLAGS)
# Creates the dependecy rules
%.d: $(SRCDIR)/%$(EXT)
#$(CPP) $(CFLAGS) $< -MM -MT $(#:%.d=$(OBJDIR)/%.o) >$#
# Includes all .h files
-include $(DEP)
# Building rule for .o files and its .c/.cpp in combination with all .h
$(OBJDIR)/%.o: $(SRCDIR)/%$(EXT)
$(CC) $(CXXFLAGS) -o $# -c $<
################### Cleaning rules for Unix-based OS ###################
# Cleans complete project
.PHONY: clean
clean:
$(RM) $(DELOBJ) $(DEP) $(APPNAME)
# Cleans only all files with the extension .d
.PHONY: cleandep
cleandep:
$(RM) $(DEP)
#################### Cleaning rules for Windows OS #####################
# Cleans complete project
.PHONY: cleanw
cleanw:
$(DEL) $(WDELOBJ) $(DEP) $(APPNAME)$(EXE)
# Cleans only all files with the extension .d
.PHONY: cleandepw
cleandepw:
$(DEL) $(DEP)
I have passed the needed libraries under LDFLAGS = -DARMA_DONT_USE_WRAPPER -lopenblas -llapack. Nevertheless, this solution does not work. It looks to me like the compiler is unable to find the armadillo library, so I must have linked it somehow wrongly. It delivers:
g++ -std=c++11 -Wall -o test obj/test.o -DARMA_DONT_USE_WRAPPER -lopenblas -llapack
/usr/bin/ld: obj/test.o: in function `TLS wrapper function for arma::arma_rng_cxx11_instance':
test.cpp:(.text._ZTWN4arma23arma_rng_cxx11_instanceE[_ZTWN4arma23arma_rng_cxx11_instanceE]+0x25): undefined reference to `arma::arma_rng_cxx11_instance'
collect2: error: ld returned 1 exit status
make: *** [Makefile:36: test] Error 1
So, aside from the obvious question (Why does this not work?), I would as well appreciate if someone could help me clarify as well the following aspects:
On the one hand, rom the message error it seems that the command run g++ -std=c++11 -Wall -o test obj/test.o -DARMA_DONT_USE_WRAPPER -lopenblas -llapack does not include the name of the cpp file I wrote (as opposed to in my manual compilation, in which it works). Nevertheless, if I do not use armadillo, the Makefile recipe above works just fine. I see the Makefile somehow looking for all cpp files in the source code folder SRC = $(wildcard $(SRCDIR)/*$(EXT)), but I cannot see where is this forwarded to the compiler. Can someone help me with that?
The other thing is that, in my manual compilation, it seems to make no difference to pass the LAPACK and BLAS libraries as CXXFLAGS or LDFLAGS, meaning both of the following commands:
g++ src/test.cpp -std=c++11 -Wall -DARMA_DONT_USE_WRAPPER -lopenblas -llapack -o test
and
g++ src/test.cpp -std=c++11 -Wall -o test -DARMA_DONT_USE_WRAPPER -lopenblas -llapack
work just fine. As far as I have been able to read, I understood the flags before -o are meant for the compiler, and those after are meant for the "linker" (whatever that is). Can someone explain me what are the main differences between the CXXFLAGS and LDFLAGS? Why both combinations work? And what is the linker?
Thank you very much for your help.
Best,
D.
The other answer is a good general introduction to compilation but if you want to know what is happening in your situation you need to first understand that answer and the difference between source files, object files, and executable files and the way that they work, then go deeper to figure out what's wrong.
As far as I have been able to read, I understood the flags before -o are meant for the compiler, and those after are meant for the "linker" (whatever that is)
No, that is not right.
Turning source files into an executable involves several steps each managed by a different tool. The compiler front-end (e.g., g++) manages the order of these. Each of these may use different options, and whenever the compiler front-end invokes one of these tools it will pass the appropriate flags from the command line for that tool. It's not the case that "only" flags before or after -o are passed to different tools; it doesn't matter where on the command line they live.
The tools involved with compilation, in the order in which they're invoked, are:
Preprocessor: this handles #include and #ifdef and #define, etc. (the lines that start with # in your source). The preprocessor takes the options -D, -I, and some others.
Compiler: this turns your source code (after preprocessing to handle all the included files etc.) into assembly code which is very low-level: basically machine code but in ASCII form. This does the bulk of the work including optimization etc. Flags like -O2, -g, and many others are used by this tool.
Assembler: this turns the assembly code into a binary format for your CPU and generates an object file (foo.o).
Linker: this takes one or more object files plus libraries and turns them into an executable. This tool uses options like -L and -l to find libraries.
There's a separate tool, the archiver (ar) which is not invoked by the compiler front-end, which is used to turn object files (foo.o) into static libraries (libfoo.a).
Note, the above is a "classical" view of building: newer compilers munge the above steps together sometimes to get either better error messages or better optimization or both.
Most of the time the first three steps are all done by a single invocation of the compiler front-end: it turns a source file into an object file. You do this once for each source file. Then at the end, another invocation of the compiler front-end takes those object files and builds an executable.
If you look at the output make prints you'll see these two steps. First you'll see the compilation step, which is controlled by this make rule:
$(OBJDIR)/%.o: $(SRCDIR)/%$(EXT)
$(CC) $(CXXFLAGS) -o $# -c $<
and runs this command:
g++ -std=c++11 -Wall -o obj/test.o -c src/test.cpp
The -c option here tells the compiler, "do all the steps up to and including the compile step, then stop and don't do the link step".
Then you will see your link command, which is controlled by this make rule:
$(APPNAME): $(OBJ)
$(CC) $(CXXFLAGS) -o $# $^ $(LDFLAGS)
and runs this command:
g++ -std=c++11 -Wall -o test obj/test.o -DARMA_DONT_USE_WRAPPER -lopenblas -llapack
What do you notice about this? The -DARMA_DONT_USE_WRAPPER is a preprocessor option, but you're passing it to the link step and not passing it to the compile step. That means when the source is compiled, that option is not present and so whatever operation it was intended to suppress (using a wrapper apparently) is not being suppressed.
You need to put preprocessor options in a make variable that is sent to the compiler / preprocessor, so it should be this:
CXXFLAGS = -std=c++11 -Wall -DARMA_DONT_USE_WRAPPER
LDFLAGS = -lopenblas -llapack
Be sure to run clean before trying to build again.
One minor thing, but generally you should use CXX for your C++ compiler and CC for your C compiler (these are the usual conventions). If you do end up trying to compile C++ source with a C compiler you are likely to have problems. Less so the other way round.
So what it happening? Roughly speaking, you have two steps:
Compilation
Linking
When you compile a small exe, you can combine these into a single steps. Makefiles generally don't as two steps is more general.
For compilation the input has a .cpp suffix and you are passing the -c flag to tell the compiler to just compile. This will result in an object file (.o suffix).
For linking, there is no -c. The inputs are object files and the output is your application.
Other suffixes are possible (.cxx, .CC etc.).
There are 4 commonly used make variables
CPPFLAGS for preprocessor flags, can be used for C and C++ compilation
CFLAGS for flags specific to C compilation
CXXFLAGS for flags specific to C++ compilation
LDFLAGS for flags specific to linking
Historically, ld was the linker (and hence LDFLAGS), but it isn't smart enough to handle C++ linking well on its own. So now it is usually the C++ compiler that performs the task of "linker driver", that is g++ controls the linking that ld does.
Finally, your specific problem. You should add the armadillo library to LDFLAGS. The best way to do that is to just add -larmadillo. If armadillo is not installed in a 'standard' location like /usr/lib then you may need to additional arguments such as
-L/path//to/armadillo_lib -Wl,-rpath,/path//to/armadillo_lib
(the first one tells the linker where the library is, the second one puts that path into the executable so that is also knows where the library is).
I'm trying to compile C++ project with gcc-make command but program giving this error. I already compiled Crypto++ and added include and lib folder but I dont know how to add this dir to gcc.
What should I do for fixing this "-lcrytopp" error?
I'm using makefile and this is line of 33-34.
$(TARGET): build $(OBJECTS)
$(CC) $(OBJECTS) -o $(TARGET) -lcryptopp
Error:
D:\Osman\CnC RA2\Mix\ccmix-crypto\ccmix-crypto>make
g++ src/mix_db_gamedb.o src/mix_db_gmd.o src/mix_header.o src/mix_db_lmd.o
src/mixid.o src/ccmix.o src/mix_file.o -o build/ccmix -lcryptopp
c:/mingw/bin/../lib/gcc/mingw32/5.3.0/../../../../mingw32
/bin/ld.exe: cannot find -lcryptopp
collect2.exe: error: ld returned 1 exit status
Makefile:34: recipe for target 'build/ccmix' failed
make: *** [build/ccmix] Error 1
Crypto++ directory:
Compile error:
You haven't added the directory containing the library to your link line. It should be something like -Lxxx where xxx is the path to the directory containing the cryptopp library:
$(TARGET): build $(OBJECTS)
$(CC) $(OBJECTS) -o $(TARGET) -Lxxx -lcryptopp
(replace xxx with the directory containing the cryptopp library)
What should I do for fixing this "-lcrytopp" error?
When working from the Crypto++ build directory on Unix compatibles, the project does not use include and lib (as your picture shows). Everything is placed in the root directory (as your picture shows).
If you perform a make install, then the directories are setup, but it appears you did not install. I should also say that MinGW is not usually tested anymore because the project is abandoned, so I'm not sure where make install actually installs to on MinGW.
To fix the compile error, tweak your make recipe:
$(TARGET): build $(OBJECTS)
$(CXX) $(CXXFLAGS) -I. $(OBJECTS) ./libcryptopp.a -o $(TARGET)
The recipe above uses CXX (C++ compiler) rather than CC (C compiler); it uses CXXFLAGS (which should be something like -DNDEBUG -g2 -O2); it calls out the header path (-I.); and it links to the static library (./libcryptopp.a). Linking to the static library will avoid your next set of problems.
You can follow MadScientist's advice and use -LXXX and -lcryptopp. You might even add a runpath with -Wl,-rpath,D:\Osman\CnC RA2\Mix\ccmix-crypto\ccmix-crypto. But at the end of the day, using -L and -l causes a fair amount of trouble. Avoid the future problems by statically linking libcryptopp.a.
Also see GNUmakefile | Compiling and Linking on the Crypto++ wiki.
Your fist picture shows ipch and Win32 directories. That usually means you built the Crypto++ library with Visual Studio. Now you are building a program with GCC. You should not mix and match compilers like that. Nothing good will come of it.
I'm trying to modify and compile uvccapture on the Raspberry Pi. I got the source from here (it's just a few files).
(I think) the only external files it needs are those of jpeglib which I downloaded from here.
When compiling, where do I put the jpeglib source files? UVCCapture has the following line:
#include <jpeglib.h>
Does that mean I should put the jpeglib source files in the same directory as the UVCCapture source files? That seems messy. How can I set up the compiler (modify the Makefile?), and where should I put the jpeglib files so that I don't need to change the uvccapture include file lines?
And a side question, how come it only includes the .h file and not the .c file? (I'm pretty new to C/C++)
Here is the Makefile:
CC=gcc
CPP=g++
APP_BINARY=uvccapture
VERSION = 0.4
PREFIX=/usr/local/bin
WARNINGS = -Wall
CFLAGS = -std=gnu99 -O2 -DLINUX -DVERSION=\"$(VERSION)\" $(WARNINGS)
CPPFLAGS = $(CFLAGS)
OBJECTS= uvccapture.o v4l2uvc.o
all: uvccapture
clean:
#echo "Cleaning up directory."
rm -f *.a *.o $(APP_BINARY) core *~ log errlog
install:
install $(APP_BINARY) $(PREFIX)
# Applications:
uvccapture: $(OBJECTS)
$(CC) $(OBJECTS) $(XPM_LIB) $(MATH_LIB) -ljpeg -o $(APP_BINARY)
Thanks
The source file (uvccapture.c) doesn't care where the header file (jpeglib.h) is -- at least it shouldn't. The compiler must be told where to look for header files; traditionally, the header files go in some directory like inc_files/, and the compiler is invoked with a command like
gcc -blah -blah -blah -Iinc_files -c -o uvccapture.o uvccapture.c
If you use Make, then Make should execute a command like that. So either edit the makefile, or put the header files in the current directory.
The sane way to use #include in C/C++ is to have source files and header files include header files. That is, in foo.c there will be a couple of lines like:
#include <bar>
#include "baz.h"
and in baz.h there might be a few lines like:
#include <vector>
#include "qux.h"
You almost never see #include foo.c, because it's almost never a good idea.
I have a project of multiple source and header files and I wrote my own Makefile by specifying the required external libraries and headers (the directory containing the OpenCV header files and the directory containing the OpenCV libraries).
When I start compiling the project, it is compiled without any errors. However when writing the code, Eclipse reports errors on some functions of OpenCV, as if it did not know these functions. Since I have listed all the required headers and libraries in the makefile (see below), why does this problem occur?
CXXFLAGS = -O3 -g -Wall -fmessage-length=0 -I./include -I/usr/local/include/opencv
LIBS = -L/usr/local/lib -lcv -lcvaux -lhighgui -lcxcore -limgproc
MAIN_PROG_OBJS = MainProgram.o src/Utilities.o src/ImageStream.o src/VideoStream.o
MAIN_PROG_TARGET = MainProgram
TEST_PROG_OBJS = TestProgram.o src/Utilities.o
TEST_PROG_TARGET = TestProgram
$(MAIN_PROG_TARGET): $(MAIN_PROG_OBJS)
$(CXX) -o $(MAIN_PROG_TARGET) $(MAIN_PROG_OBJS) $(LIBS)
$(TEST_PROG_TARGET): $(TEST_PROG_OBJS)
$(CXX) -o $(TEST_PROG_TARGET) $(TEST_PROG_OBJS) $(LIBS)
all: $(MAIN_PROG_TARGET) $(TEST_PROG_TARGET)
clean:
rm -f $(MAIN_PROG_OBJS) $(MAIN_PROG_TARGET) $(TEST_PROG_OBJS) $(TEST_PROG_TARGET)
Eclipse tries to find the errors quickly, but does not update all the time. Do not rely only on the error messages of Eclipse.
For example if you have just added a file to your project, Eclipse might still be telling you that it could not find the file while in fact it is there.
Use Project -> Clean to update the error checking of Eclipse.