Did you forget your: Username / Password ?

Microsoft

TechWell

Home

CM Basics

Getting to know your compiler

Written by Bob Aiello

Tuesday, 05 May 2009 00:00

Build Engineering is one of the most fun and exciting functions that any CM guru can work on. The Build Engineer is responsible for creating repeatable builds that are fast, reliable and help to improve the overall development process. Generally, the Build Engineer needs to get help from the developers to really understand what needs to be built and the best approach for approaching this effort. That means that you should not try to work in a vacuum! Typically, developers show me how they build for development and then I improve the process by creating a repeatable build for QA and Production. I don't always get the time to do this, but it is often essential to dig deep into the compiler that is being used for the build.

Introducing GCC
The GNU Compiler(s) have really matured over the years and now support a wide variety of languages including C, C++, Fortran, and Java. For this article, I will just discuss C and C++. The most common way to compile C++ source is with the g++ compiler.

g++ or c++
As noted in the section below the g++ compiler is also aliased to c++. You may use either, but g++ is more common.

Compilers do change so make sure that you know the version of the compiler that you are working with.

➢   g++ --version

g++ (GCC) 4.3.2 20081105 (Red Hat 4.3.2-7)
Copyright (C) 2008 Free Software Foundation, Inc.
======================================

[Editor's note - I am truncating some of the messages and disclaimers that you should read carefully when you test this on your own machine.]

Suffixes matter
The GNU compiler expects that source files with the ".c" are C Language programs, while ".cc" (or .cpp) is for C++. Here is an example of compiling a C Language program.

Compiling C Language

gcc -c hello.c

gcc hello.o -o hello

./hello

Hello World!

Of course compiling a C++ program is a little bit different.

This is the compile step

g++ -v -c -o test.o test.cpp

This is the link step

g++ -v -o mytest test.o

The -v option will turn on verbose messaging.

Look under the hood
When I peeked into the directory where my compiler is stored, I noticed that the g++ and c++ compiler had exactly the same number of bytes. (I am not going into hard links in this article.)

> ls -lt|grep g++
-rwxr-xr-x 4 root root      220728 2008-11-05 07:14 g++
-rwxr-xr-x 4 root root      220728 2008-11-05 07:14 i386-redhat-linux-g++

> ls -lt|grep c++
-rwxr-xr-x 1 root root       24756 2009-02-02 07:52 c++filt
-rwxr-xr-x 4 root root      220728 2008-11-05 07:14 c++
-rwxr-xr-x 4 root root      220728 2008-11-05 07:14 i386-redhat-linux-c++

gcc or cc

On my machine the cc "compiler" is actually just a softlink (pointing to the gcc compiler).
lrwxrwxrwx 1 root root           3 2009-05-10 19:29 cc -> gcc

Compiler Tell me what's really going on

The simple compile and link can be accomplished with these commands

> g++ -c -o test.o test.cpp
> g++ -o mytest2 test.o

But in this step I turned on verbose messaging and sent the output to a file called test_compileStep.lis

g++ -c -v -o test.o test.cpp > test_compileStep.lis 2>&1

And in this step I turned sent the output for the link step to a file called test_linkStep.lis

g++ -v -o mytest2 test.o > test_linkStep.lis 2>&1

Note that the 2>&1 sends the messages sent to the "standard" error console to the file (along with stdin).

These files will show you in great detail the steps executed by your compiler.

Some options you must know
Compile step
g++ -O0 -Wall -Wno-non-virtual-dtor -v -c -o test.o test.cpp

Link step
g++ -O0 -Wall -Wno-non-virtual-dtor -v -o mytest test.o

The -O0 (which a capital "O", followed by a zero) turns off optimization. Other options could be -O1 or -O2 pr -O3 which turns on varying levels of optimization.
The -Wall turns on extensive warnings where the -w (note the lower case "w") turns off warnings.
The -Wno-non-virtual-dtor is intended to turn off warnings related to non-virtual destructors.
(You will have to test whether or not this one works for your compiler.)

The team effort
As a build engineer, you should not be modifying the options used to compile the code without communicating to the developers on your team. However, if you spend some time learning your compiler, you will find this conversation goes much better and this is another example of where good build engineering adds real value to your team!

[Editor's note - THANK YOU !! THANK YOU!! THANK YOU!! to my great colleagues who pointed out the typo that completely changed the meaning of this paragraph!!!]

Bob Aiello is the Editor-in-Chief for CM Crossroads and a Software Engineer specializing in Software Process Improvement including Software Configuration and Release Management. Mr. Aiello has over 25 years experience as a technical manager in several top NYC Financial Services firms where he had had company-wide responsibility for CM, often providing hands-on technical support for enterprise Source Code Management tools, SOX/Cobit compliance, build engineering, continuous integration and automated application deployment. Bob is the Vice Chair of the IEEE 828 Standards working group (CM Planning) and is a member of the IEEE Software and Systems Engineering Standards Committee (S2ESC) Management Board. He is a long standing member of the Steering Committee of the NYC Software Process Improvement Network (CitySPIN), where he serves as the chair of the CM SIG. Mr. Aiello holds a Masters in Industrial Psychology from NYU and a B.S. in Computer Science and Math from Hofstra University. You may contact Mr. Aiello at raiello@acm.org or link with him at http://www.linkedin.com/in/bobaiello

Set as favorite

Bookmark

Email this