Member Avatar for lewashby

[Linux]

When using gcc and or g++ is there a way I can have two output files, one with and one without debugging symbols in one gcc/++ command? I don't want to have to write
g++ --Wall program.cpp -o program, then have to immediately run g++ --Wall -g program.cpp -o program2 in order to have both executables?

  • 4 Contributors
  • 4 Replies
  • 318 Views
  • 2 Days Discussion Span
  • Latest Post Latest Post by ipswitch

Dani AI

Generated

Short answer: a single g++ invocation cannot emit two different final binaries that were built with different flags. Two practical, maintainable approaches are (a) automate two builds (script, batch file or Make/CMake) so both debug and release get produced, or (b) build once with debug info and split/strip the debug symbols into a separate file. Both approaches avoid the error-prone manual double-compile workflow.

As suggested, a tiny script is fine for very small projects; as recommended, a build tool scales better. A minimal Makefile that keeps flags in variables (as implied) makes both targets obvious and easy to extend:

CXX = g++
CXXFLAGS = -Wall -std=c++17

SRCS = main.cpp util.cpp

debug: CXXFLAGS += -g -O0
debug: myprog-debug

release: CXXFLAGS += -O2 -DNDEBUG
release: myprog

myprog-debug: $(SRCS)
    $(CXX) $(CXXFLAGS) $(SRCS) -o $@

myprog: $(SRCS)
    $(CXX) $(CXXFLAGS) $(SRCS) -o $@

clean:
    rm -f myprog myprog-debug

If saving disk space or avoiding two full builds is important, compile once with debug info and extract the debugging symbols into a separate file, then strip the executable. The common sequence is: compile with debug info, run objcopy --only-keep-debug to save symbols, strip the binary, and objcopy --add-gnu-debuglink= to link the debug file back to the stripped binary. This produces a small runtime binary plus a separate debug file for the debugger.

Notes and caveats: keeping debug symbols and optimization flags separate is important because heavy optimization can make source-level debugging confusing. For anything beyond a toy project, adopt a simple build system so debug/release variants, install paths, and multi-file dependency handling stay correct and reproducible.

Recommended Answers

All 4 Replies

Member Avatar for David W

Write a batch file to handle this ... then call that batch file.

Member Avatar for Moschops

You have just reached the point where you are about to begin reinventing one of the standard tools of programmers; a Make tool. This, of course, is a good sign.

I advise you very strongly at this point to take nobody's recommendation, including mine. Make tools are something that nobody ever seems quite satisfied with, and as such it seems that there is an endless slow bubbling of new make tools, each one designed to solve a particular problem someone had (and, of course, in doing so that new tool suffers from some other problem that someone else won't like).

Make is the grandfather; Click Here. It has many variants, and in my opinion it remains something that everyone should have some understanding of (much as everyone should be able to read a little C), if only because it's so ubiquitous. The syntax is disconcerting and it shows its age, and there are various versions of it, but it's low-level enough that you should be able to understand every line in it and know exactly what it's doing for you. Some of the higher-level make tools have opaque abstractions which is fine, of course, but to begin with I believe it's important to understand what's going on.

Many other options are listed here: https://en.wikipedia.org/wiki/List_of_build_automation_software

As you can see, there are a lot of them. Make tools seem to be a classic attractor for pet projects.

The point is, there are standard tools in which you define what you're building, in what versions (e.g. debug build, release build) and you tell the make tool to build one. The make tool should keep track of the dependencies, recompile only what needs recompiling, and put the output files where you tell it to. In your case, you might have a debug binaries directory, and a release binaries directory. You might have a build with all the extra warnings turned on; you might have a build with the optimisations turned up all the way.

Anyway, the fact that you've now reached this point indicates clearly that you have a need for make tools. Take a look at them, pick something simple to start with, and see which one best fits your needs.

Edited by Moschops
Member Avatar for lewashby

Thanks Moschops that was helpful, although I think you vastly overestimate me. I hope one day to me actually using these tools and a regular, but for now I tinker and learn slowly and painfully.

Member Avatar for ipswitch

Oh guy, there is so many switches and you need to hit right combo ...

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.