C++ Beginner · Lesson 02 of 22

Compilation vs linking; object files and executables

The four stages, .o object files, and why a missing definition is a linker error.

Estimated time · 45–75 min

Learning goals

What you will understand

Explain compilation vs linking; object files and executables in your own words
Use it in a small robotics example
Verify the result instead of assuming it worked

Understand the idea first

The mental model

Building has stages: the preprocessor expands #include lines, the compiler turns each .cpp file into an object file (.o), and the linker joins object files and libraries into one executable. A compile error means one file is wrong; a link error means a piece is missing or defined twice.

A function can be declared (its name and types are announced) in one file and defined (its body written) in another. If you call a function that was declared but never defined, the compiler is happy and the linker reports 'undefined reference'.

Guided lesson

Work through these steps

1.
Read the compilation vs linking; object files and executables example and identify what each line owns or changes.
2.
Create a small source file, compile with -std=c++17 and warnings enabled, and run it.
3.
Change one input, predict the result before running, then compare the output.
4.
Record one compiler or runtime error and explain the correction in your own words.

Worked example

Read it before you run it

g++ -std=c++17 -c main.cpp -o main.o
# Compile only (-c): turn main.cpp into the object file main.o without linking.
g++ -std=c++17 -c status.cpp -o status.o
# Compile the second source file into its own object file.
g++ main.o status.o -o robot_status
# Link both object files into the executable robot_status.
nm -C status.o | grep report
# List the symbols in status.o (-C demangles C++ names) and look for the function report.
ls -l main.o status.o robot_status
# Show the three build outputs and their sizes.

What the example is doing

1.Read declarations from right to left: identify each value's type, name, and initial value.
2.Follow the data through each expression before considering syntax shortcuts.
3.Compile with warnings enabled; a clean build is part of the result, not an optional polish step.

Watch it run · Build and run

See what this code does

The terminal types this lesson's practice solution and runs it. The scene shows the kind of robot behaviour that code drives. It plays by itself and loops.

Practice code

Now type it yourself

Copy the starter into practice.cpp and replace every TODO with your own code. Build and run it: g++ -std=c++17 -Wall -Wextra -Wpedantic practice.cpp -o practice -pthread && ./practice

#include <iostream>

int report(int joints);  // declaration: a promise that report() exists somewhere

int main() {
  std::cout << report(6) << '\n';  // the compiler accepts this; the linker needs the body
  return 0;
}

// TODO: define report(): return joints * 2 (without it the linker says "undefined reference")

Expected output

Stuck? Show the full solution (try it yourself first)

#include <iostream>

int report(int joints);  // declaration: a promise that report() exists somewhere

int main() {
  std::cout << report(6) << '\n';  // the compiler accepts this; the linker needs the body
  return 0;
}

int report(int joints) { return joints * 2; }

Expected result

How you know it worked

After adding the shown fragment to the guided exercise with its listed headers and surrounding program, the finished program builds with -Wall -Wextra -Wpedantic.
Changing the stated input produces the result you predicted.

Practical exercise

Apply the lesson

Create main.cpp and status.cpp. Compile each with -c, then link. Next, misspell a function name in main.cpp and note the compiler error; then remove the body from status.cpp and note the linker error. Explain which stage reports each.

Before you continue

The program builds with -std=c++17 and no warnings
You can explain the key rule without reading the example
The normal and edge cases both have recorded results

If something goes wrong

The compiler reports that a name or type is unknown.

Start at the first error. Check spelling, required #include lines, and whether the declaration appears before use.

The program runs but the value is wrong.

Print the inputs and intermediate values, then check conversions, units, and collection order.