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.
Related
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.
I have a stack trace from an application that was built and run on CentOS 5.4. The application was built without debug so there are no symbols or line numbers in the stack trace, but only addresses, like so:
/opt/app/bin/myApp [0x22ec09e]
/opt/app/bin/myApp [0x1fcdf31]
/opt/app/bin/myApp [0x22ebbcb]
...
I also have the same application, but built with debug (-g). So I am able to open this binary with gdb and find out the corresponding source files, function names and line numbers corresponding to these addresses.
My question is, having this binary built with debug on CentOS 5.4, does it matter on which OS I am using gdb to resolve the symbols? If I open it with gdb on CentOS 5.4 and use info line or list, could the result differ from when doing the same on say Fedora 16? I have done a few tests doing this on CentOS 5.4 and Fedora 16 which indicates that there is no difference. However, can I trust that this is always so or could I one day find out that there could be differences under certain circumstances?
Notes: Application was written in C++ and built with g++. Please let me know if any additional information is needed to answer this question.
does it matter on which OS I am using gdb to resolve the symbols?
No: the mapping of addresses to line numbers is fixed at binary link time. Once the binary is linked, you can perform the mapping on any OS you wish.
I also have the same application, but built with debug (-g).
Note that the mapping does change depending on optimization flags you used. This would work:
# original application build
g++ -O2 foo.cc bar.cc -o app
# same with debug symbols:
g++ -O2 -g foo.cc bar.cc -o app_g
This would not work (symbols between app and app_g2 will not match):
g++ -g foo.cc bar.cc -o app_g2
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 have Eclipse CDT installed (juno) on my windows 7 computer
I have cygwin installed (able to manually create a makefile and create a .so)
I want to use the cygwin compiler in eclipse to create a .so
I created a new shared library project in eclipse told it to use the cygwin c++ compiler
do a ctrl-b and it creates a .dll
how do I get it to make a .so?
this is using windows 7
11:13:05 **** Build of configuration Debug for project cygwinc++ ****
make all
Building file: ../main.cpp
Invoking: Cygwin C++ Compiler
g++ -O0 -g3 -Wall -c -fmessage-length=0 -MMD -MP -MF"main.d" -MT"main.d" -o "main.o" "../main.cpp"
cygwin warning:
MS-DOS style path detected: C:\Users\EAIGREG\workspace\cygwinc++\Debug
Preferred POSIX equivalent is: /cygdrive/c/Users/EAIGREG/workspace/cygwinc++/Debug
CYGWIN environment variable option "nodosfilewarning" turns off this warning.
Consult the user's guide for more details about POSIX paths:
http://cygwin.com/cygwin-ug-net/using.html#using-pathnames
Finished building: ../main.cpp
Building target: cygwinc++.dll
Invoking: Cygwin C++ Linker
g++ -shared -o "cygwinc++.dll" ./main.o
cygwin warning:
MS-DOS style path detected: C:\Users\EAIGREG\workspace\cygwinc++\Debug
Preferred POSIX equivalent is: /cygdrive/c/Users/EAIGREG/workspace/cygwinc++/Debug
CYGWIN environment variable option "nodosfilewarning" turns off this warning.
Consult the user's guide for more details about POSIX paths:
http://cygwin.com/cygwin-ug-net/using.html#using-pathnames
Finished building target: cygwinc++.dll
11:13:06 Build Finished (took 390ms)
clearly this is using the wrong compiler... i know that my cygwin can create SO so how to i tell it to use the "linux" c++ compiler?
Perhaps there is a way to accomplish what I was looking for, but what I ended up doing was getting another computer running linux...
If I wanted to I could have just manually create my makefile and manually link and compile (maybe a few fancy batch files) but in the end it was just easier to have a full working eclipse environment natively in linux
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