Compile c++ using -c [closed] - c++

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question appears to be off-topic because it lacks sufficient information to diagnose the problem. Describe your problem in more detail or include a minimal example in the question itself.
Closed 8 years ago.
Improve this question
I have a simple example to test my IDE, to get ready my C++ environment.
I'm currently using Codeblocks 13.12 in Ubuntu 14.04.
When I build my program, the compiler executes the following code, and the program will throw an error when running.
g++-4.8 -Wall -fexceptions -O3 -pedantic-errors -std=c++11 -Wextra -Wall -pthread -c /home/mikeldi/workspace/codeblocks/main.cpp -o obj/Debug/main.o
g++-4.8 -o bin/Debug/test obj/Debug/main.o
ERROR:
terminate called after throwing an instance of 'std::system_error'
what(): Unknown error -1
Aborted (core dumped)
In the other hand, if I execute the following line (note that I don't use -c before main.cpp) the program will execute without any problem.
g++-4.8 -Wall -fexceptions -O3 -pedantic-errors -std=c++11 -Wextra -Wall -pthread main.cpp -o main
So, my question is:
What does the -c do that makes the program not work?
Is there any way of setting codeBlocks so it doesn't use -c?
Thanks in advance,

If your program throws an error at runtime, the problem is much more likely to be in your code than in the compiler switches you're using. With that said, there are much more significant differences between the two compiler invocations than -c. In particular, the differences are
-fexceptions -march=corei7 -g
If you add those compile switches to your command-line invocation, as with
g++-4.8 -fexceptions -march=corei7 -g -O3 -pedantic-errors -std=c++11
-Wextra -Wall -pthread main.cpp -o main
you can recompile your code and see that it probably still crashes. Find out where by stepping through your code using the debugger of your choice, since the -g flag tells the compiler to include debugging information into the generated object file.

As PeterT said in the comment, both the compiler and the linker need -pthread
once that solved, the program worked fine:
g++-4.8 -Wall -fexceptions -O3 -pedantic-errors -std=c++11 -Wextra -Wall -pthread -c /home/mikeldi/workspace/codeblocks/main.cpp -o obj/Debug/main.o
g++-4.8 -o bin/Debug/test obj/Debug/main.o -pthread
Thank you everybody.

Related

How to add Sanitizers on C++ VS Code

I want to add these santizers to VS Code.
g++ -std=c++17 -Wshadow -Wall -o "%e" "%f" -g -fsanitize=address -fsanitize=undefined -D_GLIBCXX_DEBUG
I'm using ubuntu. Help me how to do it.

GCC with -std=c++11 does not see C++ header files (via PyDSTool)

I am on a complex project built in python2.7 that uses the PyDSTool package for analysis of dynamical system. PyDSTool provides two C-based integrators - Radau and Dopri - which I want to use to integrate my system of equations whose source is coded in a bunch of C/C++ files.
I have little control on the package, and when I instantiate the integrator, I can only add headers *.H files, source files (*.C, *.CPP) and pass the directories to include in the search path of the compiler as well as libraries to link to.
Since a consistent part of the code is based on C++11 I am passing to the compiler also the argument -std=C++11.
Eventually, /PyDSTool/Generators/mixins.py launch a setup command (line 185) which in turn runs the command build_ext from distutils to which all the above flags are appended.
For the sake of clarity: the flags that I am appending are:
compile options: '-I/usr/lib64/python2.7/site-packages/numpy/core/include -I/home/maurizio/Dropbox/StabilityAnalysis_tmp -I/usr/local/pydstool/PyDSTool/integrator -I/usr/include/python2_7 -I/usr/include/numpy -I/home/maurizio/Dropbox/Ongoing_Projects/pycustommodules -I/home/maurizio/Dropbox/Ongoing_Projects/c_libraries -I/home/maurizio/Dropbox/Ongoing_Projects/c_libraries/models -I/home/maurizio/Dropbox/Ongoing_Projects/DePitta_PNAS/Software/Stability_Analysis/ -I/usr/lib64/python2.7/site-packages/numpy/core/include -I/usr/include/python2.7 -c'
extra options: '-std=c++11 -w -Wno-return-type -Wall -lpython2.7 -lm -lgsl -lgslcblas -D__DOPRI__'
The resulting compilation command as issued by PyDSTool reads:
error: Command "gcc -pthread -fno-strict-aliasing -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -D_GNU_SOURCE -fPIC -fwrapv -DNDEBUG -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -D_GNU_SOURCE -fPIC -fwrapv -fPIC -I/usr/lib64/python2.7/site-packages/numpy/core/include -I/home/maurizio/Dropbox/StabilityAnalysis_tmp -I/usr/local/pydstool/PyDSTool/integrator -I/usr/include/python2_7 -I/usr/include/numpy -I/home/maurizio/Dropbox/Ongoing_Projects/pycustommodules -I/home/maurizio/Dropbox/Ongoing_Projects/c_libraries -I/home/maurizio/Dropbox/Ongoing_Projects/c_libraries/models -I/home/maurizio/Dropbox/Ongoing_Projects/DePitta_PNAS/Software/Stability_Analysis/ -I/usr/lib64/python2.7/site-packages/numpy/core/include -I/usr/include/python2.7 -c /home/maurizio/Dropbox/StabilityAnalysis_tmp/dop853_temp/ei_network_vf.c -o /home/maurizio/Dropbox/StabilityAnalysis_tmp/dop853_temp/home/maurizio/Dropbox/StabilityAnalysis_tmp/dop853_temp/ei_network_vf.o -std=c++11 -w -Wno-return-type -Wall -lpython2.7 -lm -lgsl -lgslcblas -D__DOPRI__" failed with exit status 1
Once looking into the build.log file automatically generated by PyDSTool, it turns out that the exit status is due to the fact that the compiler does not see the C++ libraries that are in several routines/libs used by my code, e.g.
/usr/include/blitz/blitz.h:45:18: fatal error: string: No such file or directory
#include <string>
^
Compilation Terminated
Now, it is not a problem of my code, because if I compile my code as a standalone in python or through scipy.weave with the same compile and extra options pasted above, it works. It is a problem of making PyDSTool build the code within the integrator. As I am NOT practical with distutils and all gcc options I hope there is some expert here that could provide me with some insight. I suspect in fact that I am missing some options or whatever to pass to the compiler.
Just for the sake of completeness. The issue I pointed out above does not have an easy workaround. PyDSTool C-based integrators (i.e. Radau and Dopri) cannot be compiled with source code for the equations in C++ but only in C. So either you recast your code in plain C or try to edit PyDSTool integrators and recast them in C++. The first option is likely the only one currently possible (at least to some non-experts as who is writing).

gcc creates crashing code depending on optimisation

I have a rather complex multithreaded code, which I compile using gcc 4.8.1. When compiling with
g++ -c file.cc -march=native -mfpmath=sse -mpreferred-stack-boundary=4
--param inline-unit-growth=50 -ggdb3 -Wall -Wextra -Winit-self
-O2 -fPIC -funroll-loops -fforce-addr -rdynamic
the code produced crashes with segfault (which I was unable to debug, but the address of a struct all of a sudden differs from what it was when constructed, in particular, is no longer aligned to 32bytes as required by the code but only to 8bytes).
When compiling with -O1 instead, the code works fine. I then added all the optimisation flags that make the difference between -O1 and -O2. (To this end, I created two files O1-opts and O2-opts via
g++ -march=native -mfpmath=sse -mpreferred-stack-boundary=4
--param inline-unit-growth=50 -ggdb3 -Wall -Wextra -Winit-self
-O1 -fPIC -funroll-loops -fforce-addr -rdynamic
-Q --help=optimizers > O1-opts
g++ -march=native -mfpmath=sse -mpreferred-stack-boundary=4
--param inline-unit-growth=50 -ggdb3 -Wall -Wextra -Winit-self
-O2 -fPIC -funroll-loops -fforce-addr -rdynamic
-Q --help=optimizers > O2-opts
when diff O1-opts O2-opts provides the option differences). When adding all the option differences to -O1, the code generated still does not crash. This puzzles me. So my question is: shouldn't this give exactly the same result as with -O2? (and also: what is the likely cause of my problem?)
The point is that the -O2 option not only sets different flags, but also enables additional optimizations in contrast to -O1.
The FAQ section of the GCC Wiki has an appropriate entry for this.

R Makevars file to overwrite R CMD's default g++ options?

I have this standalone C++ code
that I'm trying to wrap in an R
package.
My problem is that I absolutely
want it to be compiled with the
-O3 flag on.
So in the src/Makevars file
I put:
PKG_CPPFLAGS = -I../inst/include
PKG_CXXFLAGS = -O3
CXX_STD = CXX11
and still when I install my package on my
machine, I see:
g++ -std=c++0x -I/usr/share/R/include -DNDEBUG -I../inst/include -O3 -fpic -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Wformat-security -Werror=format-security -D_FORTIFY_SOURCE=2 -g -c mycppfunctions.cpp -o mycppfunctions.o
g++ -std=c++0x -shared -Wl,-Bsymbolic-functions -Wl,-z,relro -o mycppfunctions.so mycppfunctions.o -L/usr/lib/R/lib -lR
(the dreaded -O2 flag appears to the right)
so my question is: how can I overwrite the
cpp flags used when g++ is invoked by R CMD?
Edit:
Recently, in another package, I found a way to do
something similar for a F77 code (also in an R package).
Basically, by adding this to the Makevars:
PKG_FFLAGS = $(FPICFLAGS) $(SHLIB_FFLAGS)
all: $(SHLIB)
otherf77foo.o: otherf77foo.f
$(F77) $(PGK_FFLAGS) -O3 -pipe -g -c -o otherf77foo.o otherf77foo.f
but I don't know how to do the same for a cpp code...
Edit2:
So, doing this is totally possible. Dirk Eddelbuettel question 'b)' from his answer below
guided me to the solution. So, all I had to do was to
place this in the src/Makevars file:
mycppfoo.o: mycppfoo.cpp
g++ -std=c++0x -I/usr/share/R/include -DNDEBUG -I../inst/include -fpic -g -O3 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Wformat-security -Werror=format-security -D_FORTIFY_SOURCE=2 -g -c mycppfoo.cpp -o mycppfoo.o
g++ -std=c++0x -shared -Wl,-Bsymbolic-functions -Wl,-z,relro -o mycppfoo.so mycppfoo.o -L/usr/lib/R/lib -lR
and my problem was solved!
You can't (as per a comment by Simon Urbanek on r-devel a while back).
But it should not matter as AFAIK the right-most value wins. And R puts its values to the left, and lets you add your values (eg via CXX_FLAGS from, say, ~/.R/Makevars or PKG_CXXFLAGS from the src/Makevars in your package) to the right.
So just override with -O3 and it should be -O3.
For what it is worth, my current values in ~/.R/Makevars are:
CFLAGS += -O3 -Wall -pipe -pedantic -std=gnu99
CXXFLAGS += -O3 -Wall -pipe -Wno-unused -pedantic
and you could of course throw in -mnative or your specific CPU identifier.
Lastly, if you really wanted you could edit /etc/R/Makeconf but you'd have to do that
after each upgrade of the R package. And as I argue here you do not need to as the scheme suggested here should work.
Edit: In response to your edit:
a) The clear recommendation on r-devel (please check the archives) is that you should avoid Makefile logic if you can. IIRC this echoed in the Writing R Extension manual.
b) You declared a rule to build an .o (object) file from an .f (source) file. Did you try doing the same with cpp instead of f?
Lastly, you have not explained exactly why the world is coming to an end if your file is built with -O2 rather than -O3. You should understand that as an author of source, you can't fully control with which compiler options (let alone compiler versions) people will build your package.
newedit: Okay I'm a fool. It solved the problem for Rcpp (which I don't care about), but it doesn't work for the github.com/ohdsi/cyclops.git package that I do care about. That one still gets -O2 stuck right-most. This is ridiculous. Control over command-line parameters might be the single most important piece of this entire operation. R needs a better build system.
edit: Of course after days of trouble, I figure it out right after posting. My problem was that I was using the CXX_STD = CXX11 flag. Apparently with this flag you need to use CXX11FLAGS += .... So if your Makevars file contains CXX11FLAGS += -O0 -Wall it will correctly put this to the right of the -O2 flag if you're using C++11.
No matter what I do I can't get -O0 to show up on the right. I have the following in my ~/.R/Makevars:
CFLAGS += -O0 -Wall
CXXFLAGS += -O0 -Wall
CPPFLAGS += -O0 -Wall
PKG_CFLAGS += -O0 -Wall
PKG_CXXFLAGS += -O0 -Wall
PKG_CPPFLAGS += -O0 -Wall
I have installed Rcpp from source (as a test...I'm not interested in it directly) using
install.packages(getwd(), repos = NULL, type = "source")
and that did correctly use -O0.
With my current configuration, I end up getting three different -O0's to the left and final -O2 on the right. Has anyone else run into this problem?
The software I'm installing is at github.com/ohdsi/cyclops.git, though I'm not sure what that would be important.

How to force Netbeans to only use the -ggdb compile flag without it also automatically emitting the -g flag in Makefile-Debug.mk

I’m running Netbeans 7.4 on Mavericks. In order to be able to use gdb, compilation with the -ggdb flag seems to be necessary. However, even though I specify it through the Project’s Properties/Additional Options wizard, Netbeans also emits -g during compilation. Unfortunately, it turns out that this behavior has an adverse effect when the debugging session commences. Is there any way to force Netbeans not to also emit -g?
Output during compilation:
g++ -m64 -ggdb -c -g -Werror -std=c++11 -MMD -MP -MF "build/Debug/macport_GNU-MacOSX/main.o.d" -o build/Debug/macport_GNU-MacOSX/main.o main.cpp
mkdir -p dist/Debug/macport_GNU-MacOSX
g++ -m64 -ggdb -o dist/Debug/macport_GNU-MacOSX/executable build/Debug/macport_GNU-MacOSX/main.o
Alexander.Simon#oracle.com responded here [1] to set "Development Mode" to "No Flags", then specify -ggdb in the "Additional Options".
1 - https://netbeans.org/projects/cnd/lists/users/archive/2014-02/message/12