I am trying to compile a C++ project and have been asked to use GCC. This works fine and compiles without any problems, but the code generated by GCC is around ten times slower than that produced by G++ even with full optimizations.
Is this because GCC is meant for c-programs or can I do something to make the compiler optimize more?
This is the content in my makefile:
CFLAGS = -std=c++11 -lstdc++ -O3
SRC_PATH=Loki
FILES=bench.cpp bitboard.cpp evaluation.cpp magics.cpp main.cpp misc.cpp move.cpp movegen.cpp
perft.cpp position.cpp psqt.cpp search.cpp thread.cpp transposition.cpp uci.cpp
SOURCES=$(FILES:%.cpp=$(SRC_PATH)/%.cpp)
OUTFILE=Loki.exe
all:
gcc ${SOURCES} -o $(OUTFILE) ${CFLAGS}
Related
I am new to C++ and learning RTI DDS at the moment by compiling their examples. I am currently using their make files but I want to learn how to compile individual files using gcc directly. The make files first compiles objects and links them together as per below.
g++ -DRTI_UNIX -DRTI_LINUX -DRTI_64BIT -m64 -O2 -o objs/x64Linux3gcc4.8.2/HelloPublisher.o -Isrc -Isrc/idl -I/opt/rti_connext_dds-5.2.3/include -I/opt/rti_connext_dds-5.2.3/include/ndds -c src/HelloPublisher.cpp
g++ -m64 -static-libgcc -Wl,--no-as-needed objs/x64Linux3gcc4.8.2/HelloPublisher.o -o objs/x64Linux3gcc4.8.2/HelloPublisher -L/opt/rti_connext_dds-5.2.3/lib/x64Linux3gcc4.8.2 -lnddscppz -lnddscz -lnddscorez -ldl -lnsl -lm -lpthread -lrt
How can I write a single command using g++/gcc to do both?
The usual way is
g++ -o $prog -DRTI_UNIX $moreflags $file1.cpp $file2.cpp $prog.cpp $libs
You'll have to try a bit with the myriad of arguments you got since order matters.
while using g++ (version 4.9.2) from MinGW provided with Code::Blocks IDE, I am getting incredibly huge .exe files, going up to 1000KB for a "Hello, World!" program. I use exactly the same compiling options as like it would be compiled from "inside" of Code::Blocks (mingw32-g++.exe -Wall -g hello.cpp -o hello.exe, anyway, i just copy it from the Code::Blocks log window), but unlike that way, which produced about 70KB output for Debug target and 50KB for Release, this keeps on making incredibly large output.
Did anyone else meet a similar issue?
[EDIT] My project (created only for testing Makefiles purposes) consists on two files, main.cpp and fun.cpp (no headers). Here is main.cpp:
#include<iostream>
using namespace std;
void fun(void);
int main()
{
cout<<"Hello Make!"<<endl;
fun();
return 0;
}
and here is fun.cpp:
#include<iostream>
using namespace std;
void fun()
{
cout<<"Hello from The Module!"<<endl;
}
And finally, this is my Makefile:
CC = mingw32-g++
CFLAGS = -Wall -Os -lto
all: main.o fun.o
${CC} -o hello.exe $^
relink:
mingw32-g++ -o hello.exe hello.o fun.o
main.o: main.cpp
mingw32-g++ ${CFLAGS} -c main.cpp -o $#
fun.o: fun.cpp
mingw32-g++ ${CFLAGS} -c fun.cpp -o $#
clean:
del *.o
When compiling this "project" under Code::Blocks I get the following
log
When using Makefile, the output file is 1024KB large:
(print screen)
Debug builds will usually be larger than optimized (aka "release") ones. Try adding -O2 or -O3 to your build options (or -Os to specifically optimize for size).
Also, if you don't need the debug symbols in a release build then remove -g (or remove them afterwards with the strip command).
Also; compiling with Link-Time Optimization can sometimes yield a size reduction (in addition to a performance improvement) - for that use the -lto option (in addition to one of the -O options).
The above should give you a significant size reduction.
See the gcc manual for more details on the options.
I have been writing a c++ program in Ubuntu and window8 using armadillo. Under Windows8 the program compiles without problems.
The program is just using the linear systems solver.
Under Ubuntu the compiler says
"reference to `wrapper_dgels_' not defined"
The compiler line I use is:
mpic++ -O2 -std=c++11 -Wall -fexceptions -O2 -larmadillo -llapack -lblas program.o
However, right before the error I see:
g++ module_of_the_error.o
Which is something I haven't set.
I am using code blocks in Ubuntu, and I compiled armadillo with all the libraries that cmake asked. (BLAS< LAPACK, OpenBLAS, HDF5, ARPACK, etc)
I have no clue what might be causing the problem, since the exact same code compiles in visual studio.I have tried the compiler line modifications suggested but it does not seem to work.
Any help is appreciated.
This is one trap I fell into myself one time. You will not like the likely cause of your error.
The order of the arguments to the linker matters.
Instead of
mpic++ -O2 -std=c++11 -Wall -fexceptions -O2 -larmadillo -llapack -lblas program.o
try:
mpic++ -O2 -std=c++11 -Wall -fexceptions -O2 program.o -larmadillo -llapack -lblas
I.e., put the object files to be linked into the executable before the libraries.
By the way, at this stage you are only linking files that have already been compiled. It is not necessary to repeat command line options that are only relevant for compiling. So this will be equivalent:
mpic++ program.o -larmadillo -llapack -lblas
Moreover, depending on how you installed Armadillo, you are adding either one or two superfluous libraries in that line. One of the following should be enough:
mpic++ program.o -larmadillo
or
mpic++ program.o -llapack -lblas
EDIT: as the answer by rerx states, the problem is probably just a simple ordering of the switches/arguments supplied to g++. All the -l switches need to be after the -o switch. Or in other words, put the -o switch before any -l switches. For example:
g++ prog.cpp -o prog -O3 -larmadillo
original answer:
Looks like your compiler can't find the Armadillo run-time library. The proper solution is to specify the path for armadillo run-time library using the -L switch. For example, g++ -O2 blah.cpp -o blah -L /usr/local/lib/ -larmadillo
Another possible solution is to define ARMA_DONT_USE_WRAPPER before including the armadillo header, and then directly link with LAPACK and BLAS. For example:
#define ARMA_DONT_USE_WRAPPER
#include <armadillo>
More details are available at the Armadillo frequently asked questions page.
I'm trying to write a class that needs to deallocate some memory, so I've defined a custom destructor. This is compiled as a shared library. However, when I try to compile a basic program to use that library, I'm getting the usual "undefined reference" error when a definition cannot be found. If I remove the destructor, this does not occur.
Here's a stripped-down example:
Header file:
#ifndef _SKYMAP_H_
#define _SKYMAP_H_
#include <vector>
#include "TCanvas.h"
class BL_Skymap {
public:
BL_Skymap();
~BL_Skymap();
protected:
TCanvas mCanvas;
};
#endif //_BENSLIBRARY_SKYMAP_H_
Source file:
\#include "BL_Skymap.h"
BL_Skymap::BL_Skymap()
{
}
BL_Skymap::~BL_Skymap()
{
}
Now the program I'm using is simply this:
\#include "BL_Skymap.h"
int main()
{
BL_Skymap map;
return(0);
}
Note that I'm using the ROOT analysis package (that's the TCanvas object). When I compile the small program above, I get the following errors (the Skymap class is compiled into libMyLibrary.so):
g++ test.cpp -o test -lMyLibrary `root-config --cflags --glibs`
/usr/lib/gcc/x86_64-linux-gnu/4.7/../../../../lib/libMyLibrary.so: undefined reference to 'TCanvas::~TCanvas()'
/usr/lib/gcc/x86_64-linux-gnu/4.7/../../../../lib/libMyLibrary.so: undefined reference to 'TCanvas::TCanvas(bool)'
Please note that the root package gives a utility to generate the required compiler flags, which is the purpose of root-config --cflags --glibs above.
What am I missing here?
UPDATE: I've written a Makefile to perform the compilation of my library, which executes the following:
g++ -Wall -Wextra -ansi -pedantic --std=c++11 -Isrc -Ihdr -MM -MT 'obj/BL_Skymap.o' src/BL_Skymap.cpp -MF BL_Skymap.d `root-config --cflags --glibs`
g++ -Wall -Wextra -ansi -pedantic --std=c++11 -Isrc -Ihdr -fPIC -o obj/BL_Skymap.o -c src/BL_Skymap.cpp `root-config --cflags --glibs`
g++ -Wall -Wextra -ansi -pedantic --std=c++11 -shared obj/*.o -o libMyLibrary.so
UPDATE2: I found the problem - in the final step in the compilation above, I was forgetting to add the call to root-config and therefore libMyLibrary.so wasn't linking to the ROOT libraries like it should have.
As stated in an update to the original question, my problem was that I was using the relevant flags for the ROOT libraries when I was compiling the BL_Skymap.o object file, but not when I was linking the object file together to make the libMyLibrary.so file.
Adding the ROOT flags to this final step fixed the problem.
Right now I am compiling the sqlite3 code with the following options:
gcc -c -lpthread -DSQLITE_THREADSAFE=1 sqlite3.c
g++ -o test test.cc sqlite3.o -ldl -lpthread
And this works just fine.
But I saw in some projects, that the define flag -DSQLITE_THREADSAFE=1 is also in the g++ compiler call listet. Is this required or redundant?
The SQLITE_THREADSAFE symbol is needed only when compiling the SQLite code itself.
Adding it to other compiler calls is superfluous, but does not hurt.