I tried to build my program via Yocto and faced to problem of large size of executable. After some investigation I found out that my program was built with GCC flag -g (produce debugging info). It's turned out this flag is setted in file bitbake.conf:
DEBUG_FLAGS ?= "-g -feliminate-unused-debug-types ${DEBUG_PREFIX_MAP}"
# Disabled until the option works properly -feliminate-dwarf2-dups
FULL_OPTIMIZATION = "-O2 -pipe ${DEBUG_FLAGS}"
DEBUG_OPTIMIZATION = "-O -fno-omit-frame-pointer ${DEBUG_FLAGS} -pipe"
SELECTED_OPTIMIZATION = "${#d.getVar(oe.utils.vartrue('DEBUG_BUILD', 'DEBUG_OPTIMIZATION', 'FULL_OPTIMIZATION', d))}"
So flag -g is used in every build, no difference DEBUG_BUILD variable is defined or not. The only workaround that I found is to set ${DEBUG_FLAGS} = " " in my program recipe.
So, my question is: is there any better solutions? And is it normal, that all packages in Yocto are built with debug flag? It seems to be overrun solution, especially for embedded devices.
See #Parthiban comments. There is no problem in essence.
Related
everyone.
I'm try to build CPU2017 intrate and fprate test set on aarch64 server with gcc9.3. All the benchmark build successed, except 510.parest_r. Then i try build it with gcc9.4, meet the same error. I used the Example-gcc-linux-aarch64.cfg as configure file, just edit the gcc path.
Here is the failed info:
/home/gcc9.3/bin/g++ -std=c++03 -mabi=lp64 -c -o source/me-tomography/synthetic_data.o -DSPEC -DNDEBUG -Iinclude -I. -DSPEC_AUTO_SUPPRESS_OPENMP -O3 -DSPEC_LP64 source/me-tomography/synthetic_data.cc
/home/gcc9.3/bin/g++ -std=c++03 -mabi=lp64 -c -o source/multigrid/mg_base.o -DSPEC -DNDEBUG -Iinclude -I. -DSPEC_AUTO_SUPPRESS_OPENMP -O3 -DSPEC_LP64 source/multigrid/mg_base.cc
/home/gcc9.3/bin/g++ -std=c++03 -mabi=lp64 -c -o source/me-tomography/measurements.o -DSPEC -DNDEBUG -Iinclude -I. -DSPEC_AUTO_SUPPRESS_OPENMP -O3 -DSPEC_LP64 source/me-tomography/measurements.cc
init2.c:52: MPFR assertion failed: p >= 2 && p <= ((mpfr_prec_t)((mpfr_uprec_t)(~(mpfr_uprec_t)0)>>1))
during GIMPLE pass: forwprop
source/me-tomography/measurements.cc: In constructor 'METomography::Measurements::ReferencedMeasurements::RatioMinusRatio<dim, number>::RatioMinusRatio(const libparest::Slave::Stationary::ProblemDescription&, const dealii::Function<dim>&, const std::set<unsigned char>&) [with int dim = 3; number = double]':
source/me-tomography/measurements.cc:1739:7: internal compiler error: Aborted
1739 | RatioMinusRatio<dim,number>::
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~
0xafbd97 crash_signal
../.././gcc/toplev.c:326
0xffff9e304d78 __GI_raise
../sysdeps/unix/sysv/linux/raise.c:51
0xffff9e2f1aab __GI_abort
/build/glibc-RIFKjK/glibc-2.31/stdlib/abort.c:79
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
specmake: *** [/home/spec/cpu2017_aarch64/benchspec/Makefile.defaults:356: source/me-tomography/measurements.o] Error 1
specmake: *** Waiting for unfinished jobs....
The failed info seem be caused by the MPRF float percision setting?
I tried build 510.parest_r with llvm-10, build success.
By the way, i build same gcc9.3 in x86_64 server, build 510.parest_r success.
You've found a bug in an older version of GCC (or possibly your system's RAM is failing, but unlikely if it consistently crashes at the same place). Or perhaps a bug in MPFR, although that seems less likely.
If you preprocess that source (add -E or -save-temps to the command line that crashed) and put it on https://godbolt.org/, does it still crash the same way with current ARM64 GCC, e.g. a nightly build of trunk? (https://godbolt.org/z/K6GnrYrj1 is ARM64 GCC trunk, with your command line args without the preprocessor stuff, which won't matter when compiling CPP output.)
If it still crashes with current GCC, then file a bug report on https://gcc.gnu.org/bugzilla/, ideally with a MCVE of the part of the source that triggers the bug. (Remove as many parts of the file as you can while preserving the crash behaviour. e.g. take out tons of stuff, undo if that makes it compile.)
If it doesn't crash with newer GCC, it might already be a known bug, or got fixed by accident, or a different MPFR or other library version mattered. In that case, maybe not worth reporting it upstream. Or if you do make sure to include the fact that the range of affected versions doesn't include GCC12 or current trunk. Probably this Stack Overflow Q&A is sufficient for future users to know that it's a known bug.
To be able to debug and fuzz a whole Linux distribution, I would like to set ASAN (AddressSanitizer, https://en.wikipedia.org/wiki/AddressSanitizer) as default option to gcc. So normally to achieve what I want, generally, I set the following variables before to compile a linux package:
CFLAGS="-fsanitize=address,undefined -Wformat -Werror=format-security -Werror=array-bounds -g"
CXXFLAGS="-fsanitize=address,undefined -Wformat -Werror=format-security -Werror=array-bounds -g"
LDFLAGS="-fsanitize=address,undefined"
and try to compile and run my code. I would like to have it default to gcc.
One option to do it is using spec files: https://gcc.gnu.org/onlinedocs/gcc/Spec-Files.html. However I didn't find a way to set a "catch all rules" to compile and link all my c/c++ code with AddressSanitizer.
My questions are:
Any example how to do it using spec files?
Is that the best approach to do it?
Any other alternative approach?
First of all, be sure to take a look at existing whole-distro Asan enablings in Tizen (also here) and Gentoo.
In general there are two main approaches:
customize your build system to enable Asan by default, usually using CFLAGS and CXXFLAGS; this won't always work because many packages ignore them (I think that's what Hanno Boeck did in Gentoo)
replace /usr/bin/gcc, /usr/bin/g++ and /usr/bin/cc (and may x86_64-linux-gnu-gcc, x86_64-linux-gnu-g++) with wrappers which would add Asan flags and redirect calls to original executables (this is the approach we eventually took in Tizen and found it very successful)
As a side note, I'd suggest to add the following options
CFLAGS += -fsanitize-recover=address,undefined
otherwise boot will fail at too early stages. Also look at suggested settings ASAN_OPTIONS in above links, it took people long time to figure them out.
I am using g++ 4.8.4 on Linux 14.04 x64. I am compiling my project with -O3 and -flto flags both during compilation and linking i.e., both CFLAGS and LDFLAGS in my Makefile have these options.
I just discovered that the optimized binary behaves differently (i.e., wrongly) when it comes to computations involving float/double. Removing the -O3 from LDFLAGS alone seems to be solving the problem.
I remember reading somewhere that it is generally safe to specify the same set of optimization flags to both the compiler and the linker. Am I wrong in my understanding? Thanks in advance.
While using LTO, compiler during compilation step dumps intermediate code representation (a.k.a. GIMPLE) into special sections of the object files.
Actual compilation to machine codes and optimization happens during linking stage.
So yes, if your code is causing UB or just mis-optimized with -O3 option, it might behave differently (as expected) if you change it to -O0, -Og etc
So you have to find out whether it is your code misbehaving, or actual GCC LTO bug
I'm trying to build google-glog on Mac OS X 10.8, using following options:
./configure CXX='clang++' CXXFLAGS='-std=c++11 -stdlib=libc++'
Despite that the library gets linked with libstdc++.
Why, and how to fix this?
It's better to put 'dialect' and runtime flags in the compiler variable, since it will use those flags for linking - not just source compilation: CXX="clang++ -std=c++11 -stdlib=libc++"
Save CXXFLAGS for things like -W -Wall -O2 -march=xxx, etc.
Found out that you could use the build variable
LIBS+="-stdlib=libc++"
Seems to me a better place than the compiler variables.
I'm trying to generate a python wrapper for a C++ library that I am putting together. I have just come across SWIG and am trying to use this in conjunction with distutils. I'm modifying someone elses code, so odd errors were to be expected but this one is just confusing.
I've managed to generate a c++ wrapper file with SWIG and am now attempting to run a modified version of setup.py in order to install the wrapper (which itself may or may not work, but I'll cross that bridge when it comes to it.) When doing this compiler errors pop up about inability to include header files. Specifically - string, ostream, sstream, map and vector. All of which are standard libraries, included as "include ".
The code itself compiles, but in trying to create a wrapper this way it does not.
I'm not entirely sure what information is relevant to this but this is how the extension is made:
## Extension definition
import os
wrapsrc = './project_rewrite_wrap.c'
incdir_src = os.path.abspath('../include/project')
incdir_build = os.path.abspath('../include/project')
libdir = os.path.abspath('../lib')
ext = Extension('_project_rewrite',
[wrapsrc],
include_dirs=[incdir_src, incdir_build],
library_dirs=[libdir, os.path.join(libdir,'.libs')],
libraries=['ProjectMain'])
The gcc command that is run is:
gcc -pthread -fno-strict-aliasing -DNDEBUG -g -fwrapv -O2 -Wall -Wstrict-prototypes -fPIC -I/home/ben/Project/rewrite/include/Project -I/home/ben/Project/rewrite/include/Project -I/usr/include/python2.6 -c ./project_rewrite_wrap.c -o build/temp.linux-i686-2.6/./project_rewrite_wrap.o
Which results in errors such as:
./project_rewrite_wrap.c:2696:18: error: string: No such file or directory
Any thoughts would be greatly appreciated, thanks.
You are compiling C code - the headers you mention are part of C++, not C. To compile as C++ code, use the g++ driver instead of gcc, and give the source files a .cpp extension instead of .c.