I've been looking to modify the build flags under Arduino's IDE 1.x, or even the Arduino CLI (which I haven't used but am willing to adopt) such that I can undefine -std=gnu++11 and instead define -std=gnu++14
I found a question related to this which gives me almost what I need:
Arduino 1.0.6: How to change compiler flag?
But it only shows how to add flags, not to remove them. I found another related post about changing arduino to GNU C++17 but the answer was it's not possible.
In this case, I know it's possible, as I do it in Platform IO in order to use the htcw_gfx library. It works great on most platforms that will run GFX reasonably anyway.
But I just don't know how to fiddle with Arduino to get it to dance the way I need to.
Any help would be greatly appreciated.
You can modify the default compile flags in the hardware/arduino/avr/platform.txt file.
$ grep -n "std" hardware/arduino/avr/platform.txt
23:compiler.c.flags=-c -g -Os {compiler.warning_flags} -std=gnu11 -ffunction-sections -fdata-sections -MMD -flto -fno-fat-lto-objects
28:compiler.cpp.flags=-c -g -Os {compiler.warning_flags} -std=gnu++11 -fpermissive -fno-exceptions -ffunction-sections -fdata-sections -fno-threadsafe-statics -Wno-error=narrowing -MMD -flto
For some linux systems the following would work to automatically do this:
dirname $(realpath $(which arduino)) | xargs -I{} sed -i "s/\(std=gnu++1\)1/\14/" {}/hardware/arduino/avr/platform.txt
But this is not very portable, and will not work if the user has installed Arduino with Snap (as snap has these files mounted RO).
Sources:
https://stackoverflow.com/a/28047811/6946577
https://stackoverflow.com/a/55254754/6946577
Related
I'd like to ensure that a large set projects are build with the -fno-omit-frame-pointer flag for easier debugging with tools like ebpf.
One way of course would be to modify the build scripts of each of these projects, but that is a lot of work.
I've come across the possibility to configure gcc with --enable-frame-pointer which restores the old default from the early gcc4.x days of using -fno-omit-frame-pointer.
I've built gcc from source like that and confirmed:
❯ ./bin/gcc -m32 -O3 -Q --help=optimizers | grep omit
-fomit-frame-pointer [disabled]
❯ ./bin/gcc -m64 -O3 -Q --help=optimizers | grep omit
-fomit-frame-pointer [enabled]
Is anyone aware of a possibility to extend the effect of --enable-frame-pointer to the 64bit targets?
I believe you are using an older version of GCC because support of this flag on x64 has been enabled some time ago (see e.g. this commit).
We have a complex hierarchical make file system where the CXXFLAGS is appended in several places (several separate makefiles of individual libraries).
There's one master file that seems to be getting included in every other make file. So I specified the -fno-omit-frame-pointer flag there.
When I compile, I see the above flag and after that I see -O2. My question is, if the -O2 flag sets -fomit-frame-pointer, will the latest setting take effect?
With gcc/g++ you can use the -Q --help=optimizers flags to find out the exact set of optimizations that are enabled.
With my version of gcc I get:
$ gcc -Q --help=optimizers -O2 | fgrep omit-frame-pointer
-fomit-frame-pointer [enabled]
and
$ gcc -Q --help=optimizers -fno-omit-frame-pointer -O2 | fgrep omit-frame-pointer
-fomit-frame-pointer [disabled]
So -O2 doesn't seem to overwrite the previous -fno-omit-frame-pointer.
Anyway check your environment.
Motivation
Xcode provides the ability to manipulate whatever compiler/linker toolchain is needed, but default Xcode configuration assumes Mac SDK and adds a number of default flags that do not appear anywhere in the project itself.
If these flags could be disabled/removed, Xcode's native build system could be used to control foreign compilers/toolchains such as xtensa-elf-gcc and surrounding tools, while gaining the benefit of Xcode's code highlighting and clang's analytics. This would be a strongly preferable option to the external makefile option that Xcode supports directly, which does not integrate particularly nicely with the rest of Xcode.
Motivation TL;DR
If Xcode's default flags could be disabled, Xcode could directly support compiling code for the ESP8266 (using CC=xtensa-elf-gcc).
The default flags (which assume Mac OS) are not supported by xtensa-elf-gcc and prevent its use.
The flags are the only reason this does not work.
Example
The most basic compilation produces a clang command with these flags:
-x c
-arch x86_64
-fmessage-length=0
-fdiagnostics-show-note-include-stack
-fmacro-backtrace-limit=0
-std=gnu99
-Wno-trigraphs
-fpascal-strings
-O0
-fno-common
-Wno-missing-field-initializers
-Wno-missing-prototypes
-Werror=return-type
-Wdocumentation
-Wunreachable-code
-Werror=deprecated-objc-isa-usage
-Werror=objc-root-class
-Wno-missing-braces
-Wparentheses
-Wswitch
-Wunused-function
-Wno-unused-label
-Wno-unused-parameter
-Wunused-variable
-Wunused-value
-Wempty-body
-Wconditional-uninitialized
-Wno-unknown-pragmas
-Wno-shadow
-Wno-four-char-constants
-Wno-conversion
-Wconstant-conversion
-Wint-conversion
-Wbool-conversion
-Wenum-conversion
-Wshorten-64-to-32
-Wpointer-sign
-Wno-newline-eof
-DDEBUG=1
-isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.12.sdk
-fasm-blocks
-fstrict-aliasing
-Wdeprecated-declarations
-mmacosx-version-min=10.12
-g
-Wno-sign-conversion
-Winfinite-recursion
-iquote [generated-files.hmap]
-I[own-target-headers.hmap]
-I[all-target-headers.hmap]
-iquote [project-headers.hmap]
-I[Build/Products/Debug/include]
-I[Build/Intermediates/libESP8266.build/Debug/libESP8266.build/DerivedSources/x86_64]
-I[Build/Intermediates/libESP8266.build/Debug/libESP8266.build/DerivedSources]
-F[Build/Products/Debug]
-MMD
-MT dependencies
-MF [Build/Intermediates/libESP8266.build/Debug/libESP8266.build/Objects-normal/x86_64/main.d]
--serialize-diagnostics [Build/Intermediates/libESP8266.build/Debug/libESP8266.build/Objects-normal/x86_64/main.dia]
-c /Users/asher/Projects/Arduino/libESP8266/main.c
-o [main.o]
Obviously a few of these are more or less necessary (-c, -o, the various -Is, etc.) but most ought to be totally optional.
The Question
So where are they coming from? I've tried editing the basic template, and even after reducing all Mac related aspects, the result is the same. Are they added programmatically somewhere? If so, it is (presumably) in DevToolsCore or IDEFoundation?
They come from XCode "Build Settings". You could add your own compiler via "Build Options". Does that not work for you?
You could also configure Alternative Toolchains in XCode (never tried it).
There is an answer, but it's not a convenient one.
Xcode build implementation can be found at:
/Applications/Xcode.app/Contents/PlugIns/Xcode3Core.ideplugin
The core definition appears to be assembled from .xcspec files in various plugins that can be found in:
/Applications/Xcode.app/Contents/PlugIns/Xcode3Core.ideplugin/Contents/SharedSupport/Developer/Library/Xcode/Plug-ins
In particular, for clang and ld, check out:
/Applications/Xcode.app/Contents/PlugIns/Xcode3Core.ideplugin/Contents/SharedSupport/Developer/Library/Xcode/Plug-ins/Clang\ LLVM\ 1.0.xcplugin/Contents/Resources/Clang\ LLVM\ 1.0.xcspec
/Applications/Xcode.app/Contents/PlugIns/Xcode3Core.ideplugin/Contents/SharedSupport/Developer/Library/Xcode/Plug-ins/CoreBuildTasks.xcplugin/Contents/Resources/Ld.xcspec
Depending what you are looking for, you may have to dig. If you're looking for a specific build setting, find it in the Xcode build settings inspector and then search text contents for the corresponding variable name.
Theoretically the .xcspec files allow bundle identifiers and inheritance descriptions to assemble whatever build results you want. As far as I know, these details are not well documented / not documented at all.
Since Apple has restricted Xcode plugins to Apple only, it may not be possible to extend the build definition in a sensible way at the user level. It is possible to modify the default system, but then you end up with only the modified version.
Perhaps others have figured out or will later figure out more about how to take advantage of this setup, in which case I will update the answer to reflect our best knowledge.
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).
I'm using RcppEigen to write some C++ functions for my R code, and I'd like to optimize their compilation as much as possible. When I've used Eigen in the past, I've gotten a significant boost from -O3 and -fopenmp. Following Dirk's advice, I edited ~/.R/Makevars so that my Eigen code would be compiled with these flags:
CPPFLAGS=-O3 -fopenmp
This works--when I check what's happening during compilation (ps ax | grep cpp) I see:
27097 pts/6 R+ 0:00 /usr/libexec/gcc/x86_64-redhat-linux/4.4.7/cc1plus -quiet -I/usr/include/R -I/home/sf/R/x86_64-redhat-linux-gnu-library/3.0/Rcpp/include -I/home/sf/R/x86_64-redhat-linux-gnu-library/3.0/RcppEigen/include -D_GNU_SOURCE -D_REENTRANT -DNDEBUG -D_FORTIFY_SOURCE=2 file69b757e053ad.cpp -quiet -dumpbase file69b757e053ad.cpp -m64 -mtune=generic -auxbase-strip file69b757e053ad.o -g -O3 -O2 -Wall -fopenmp -fpic -fexceptions -fstack-protector --param ssp-buffer-size=4 -o -
The flags I wanted are there, -O3 and -fopenmp. But I also see -O2 there, which is presumably the system-wide default (I verified this by removing ~/.R/Makevars and indeed, -O2 is there but -O3 and -fopenmp are not.)
So the question: how do I get rid of the -O2? Or, does it actually matter? The g++ man page says:
-O3 Optimize yet more. -O3 turns on all optimizations specified by -O2 and also
turns on the -finline-functions, -funswitch-loops, -fpredictive-commoning, -fgcse-
after-reload, -ftree-vectorize and -fipa-cp-clone options.
So maybe it's fine to have both -O2 and -O3?
I think you need CXXFLAGS not CPPFLAGS in your ~/.R/Makevars
I set Makevars in the following repo to benchmark various C++ compiler flags in R/Rcpp
https://github.com/jackwasey/optimization-comparison
I use a function from https://github.com/jimhester/covr to do that programmatically, if that's of use to you.
Also, did you see the following? R: C++ Optimization flag when using the inline package