I use meson 0.53.2 on ubuntu 20.04.
I would like to have a maximally optimized executable (-Ofast) but contain all debug symbols (-g3)
If I use --buildtype=release it optimizes -O2 and the executable contains no debug symbol.
If I use --buildtype=debug it does not optimize at all and uses -g.
If I use --buildtype=debugoptimized it optimizes -O2 and uses -g.
I tried to use --debug which seems not to work, because the executable does not contain any debug symbol. Instead if I use -Ddebug=true the debug symbols are there but with the flag -g.
So how do I get gcc to compile with -Ofast -g3 flags in the least dirty way possible?
From the commandline, you can switch higher level of optimization with option optimization=3. It gives you -O3 instead -O2.
By editing meson script, you can set any flags.
if get_option('buildtype') == 'custom'
add_project_arguments('-Ofast', '-g3', language : 'cpp')
endif
And in case you cannot modify meson script, you may alter environment variables
CXXFLAGS="-Ofast -g3" meson --buildtype=custom build_c
And --reconfigure seems to not see environment variables.
Related
A directory teeming with demonstration files called ncurses-examples-20200725 is available here:
[ftp://ftp.invisible-island.net/ncurses-examples/current/ncurses-examples.tar.gz][1]
I wanted to study the workings of the form_driver_w example so I built the programs in accordance with the README file.
If I run ./form_driver_w, the result is a command line statement: "This program requires the wide-ncurses and forms library".
That outcome occurs because the following statement is not true:
#if USE_WIDEC_SUPPORT && USE_LIBFORM && (defined(NCURSES_VERSION_PATCH) && NCURSES_VERSION_PATCH >= 20131207)
Trying to trace how and where in the labyrinth of header files and compiler switches USE_WIDEC_SUPPORT is set to true is diabolically difficult. Furthermore, since the source code uses form_driver_w, I would have expected the compiler to link to ncursesw. However the compiler call is like this:
gcc -g -O2 -o form_driver_w ../ncurses-examples-20200725/form_driver_w.o ../ncurses-examples-20200725/popup_msg.o -L/lib64 -I. -I. -I../test -DHAVE_CONFIG_H -DDATA_DIR=\"/usr/local/share\" -D_DEFAULT_SOURCE -D_XOPEN_SOURCE=600 -D_XPG5 -g -O2 -DNCURSES_STATIC -lform -lmenu -lpanel -lncurses -lutil -lm
My Debian Bullseye installation includes a binary called form_driver_w in the /usr/lib/ncurses/examples/ directory. That binary runs correctly. I do not know how it was compiled.
Compiling and running form_driver_w must be a trivial task. Does anybody know how to do it?
You'd have to configure using ncursesw:
configure --with-screen=ncursesw
(and, of course, have the development library available).
The place to find this information is by running
configure --help
which lists a few options:
General Options:
--disable-stripping do not strip (debug info) installed executables
--enable-string-hacks work around bogus compiler/loader warnings
--with-pkg-config{=path} enable/disable use of pkg-config
--disable-echo do not display "compiling" commands
Curses Version-dependent Options:
--with-ncurses-wrap-prefix naming-prefix for ncurses wrapped-variables
--disable-widec disable checks for wide-character functions
--with-curses-dir=DIR directory in which (n)curses is installed
--with-screen=XXX use specified curses-libraries
--with-ncursesw use wide ncurses-libraries
--with-ncurses use ncurses-libraries
--with-pdcurses compile/link with pdcurses X11 library
--with-curses-colr compile/link with HPUX 10.x color-curses
--with-curses-5lib compile/link with SunOS 5lib curses
--with-Xaw3d link with Xaw 3d library
--with-Xaw3dxft link with Xaw 3d xft library
--with-neXtaw link with neXT Athena library
--with-XawPlus link with Athena-Plus library
--with-x use the X Window System
--with-x11-rgb=FILE file containing X11 rgb information (EPREFIX/lib/X11/rgb.txt)
--with-form-libname=XXX override form basename of library
--with-menu-libname=XXX override menu basename of library
--with-panel-libname=XXX override panel basename of library
--disable-panel disable checks for panel functions
--disable-menu disable checks for menu functions
--disable-form disable checks for form functions
Testing/development Options:
--enable-warnings test: turn on gcc compiler warnings
--with-dmalloc test: use Gray Watson's dmalloc library
--with-dbmalloc test: use Conor Cahill's dbmalloc library
--with-valgrind test: use valgrind
--disable-leaks test: free permanent memory, analyze leaks
--disable-rpath-hack don't add rpath options for additional libraries
Hi I am trying to build a compile_commands.json on windows with Scons build system and all other possibilities have failed.
I decided to use the Clang -MJ option to do this as this seems the easiest solution available.
The issue is that it isnt clear how I would go about doing this with the Scons build system; Basically I have to add -MJ myfilename.o.json to every build command. I am currently building a Library with multiple sources files like this :
library = env.StaticLibrary(target=result_path + '/' + result_name, source=sources)
Essentially at the end I should have : clang++ -target x86_64-pc-windows-gnu -MJ AABB.o.json -o src/core/AABB.o -c -m64 -g -O3 -std=c++14 -Wwrite-strings -I. -I/c/GodotLibraries/godot_headers -Iinclude -Iinclude/core src/core/AABB.cpp
Thanks in advance,
`
You are trying to set special compiler flags for your current build environment. This is done by appending the new flags to the correct environment variable. Depending on what build process (=Builder) you want to use, the corresponding single build actions (=Actions) might use different variables. The User Guide contains an Appendix A "Construction Variables", listing the default variables and their synopsis.
In your case the CCFLAGS is relevant and can be used like this:
env = Environment()
env.Append(CCFLAGS=['-MJ','AAB.o.json','-m64','-g','-O3'])
env.Program(...)
In the same way you can make SCons use the clang compiler, by setting the CXX variable accordingly:
env = Environment()
env['CXX']='clang'
env.Append(CCFLAGS=['-MJ','AAB.o.json','-m64','-g','-O3'])
env.Program(...)
I hope this lets you get the general idea behind the Builder/Action setup in SCons: The basic structure of the executed command is always the same for each Builder, but you can influence the final output by setting and overwriting those environment variables that get expanded.
As of SCons 4.0.0, you can have SCons build the compilation database like this:
env.Tool('compilation_db')
env.CompilationDatabase('compile_commands.json')
Is there a way to know at runtime that a process is compiled with the '-g' option?
I would like to operate differently in debug mode and release mode. Without using something like the -DDEBUG macro.
While compiling some libraries (spatialite 3.0.1, geos 3.3.3 and others) I've noticed that running ./configure results in a makefile that contains lines like this
CFLAGS = -g -O2
CXXFLAGS = -g -O2
That means that debug symbol generation is enabled by default. What I want is to disable debug compiling mode without manual makefile editing. I've ran ./configure --help for both of libraries mentioned above, but I have not found any option to get desired result. I feel that the solution should be very simple, but I'm stuck on this since I'm not very familiar with building software from sources.
OS: Linux Red Hat Enterprise 6
Assuming you're talking about autoconf/automake:
Why not just keep the debugging symbols and let anybody who doesn't like them make install-strip?
You can pass CFLAGS and CXXFLAGS along with configure script
./configure CFLAGS="-O2" CXXFLAGS="-O2"
I've got a proprietary program that I'm trying to use on a 64 bit system.
When I launch the setup it works ok, but after it tries to update itself and compile some modules and it fails to load them.
I'm suspecting it's because it's using gcc and gcc tries to compile them for a 64 bit system and therefore this program cannot use these modules.
Is there any way (some environmental variables or something like that) to force gcc to do everything for a 32 bit platform. Would a 32 bit chroot work?
You need to make GCC use the -m32 flag.
You could try writing a simple shell script to your $PATH and call it gcc (make sure you don't overwrite the original gcc, and make sure the new script comes earlier in $PATH, and that it uses the full path to GCC.
I think the code you need is just something like /bin/gcc -m32 $* depending on your shell (the $* is there to include all arguments, although it might be something else – very important!)
You may get a 32-bit binary by applying Alan Pearce's method, but you may also get errors as follows:
fatal error: bits/predefs.h: No such file or directory
If this is the case and if you have apt-get, just install gcc-multilib
sudo apt-get install gcc-multilib
For any code that you compile directly using gcc/g++, you will need to add -m32 option to the compilation command line, simply edit your CFLAGS, CXXFLAGS and LDFLAGS variables in your Makefile.
For any 3rd party code you might be using you must make sure when you build it to configure it for cross compilation. Run ./configure --help and see which option are available. In most cases you can provide your CFLAGS, CXXFLAGS and LDFLAGS variables to the configure script. You also might need to add --build and --host to the configure script so you end up with something like
./configure CFLAGS=-m32 CXXFLAGS=-m32 LDFLAGS=-m32 --build=x86_64-pc-linux-gnu --host=i686-pc-linux-gnu
If compilation fails this probably means that you need to install some 32 bit development packages on your 64 bit machine