An introduction to the build pipeline, and how we can orchestrate it manually

Before working with CMake, it's useful to understand the tools it orchestrates. This lesson guides you through setting up a C++ toolchain.

Building C++ Programs

Walking through the steps of the C++ compilation process, from source code to machine code.

The Compilation Pipeline

The linker's role in the build process, how it resolves symbols to combine object files, and how to troubleshoot common errors.

Object Files and the Linking Process

The difference between static and dynamic libraries, how to create them, and the trade-offs between them.

Static and Shared Libraries

The C++ Build Process

Recommended approaches for managing large projects and the libraries that they depend on

Learn how to structure your C++ projects for scalability and maintainability, from basic directory layouts to managing multiple modules.

Organizing a C++ Project

Learn to manage third-party libraries in C++, covering include/library paths, static vs. shared libraries, versioning, and platform differences.

Managing Libraries and Dependencies

An introduction to traditional build tools like Makefiles and IDE projects, highlighting the maintenance, scalability, and cross-platform challenges that result

Automated Build Systems and Their Limitations

Project Structure and Dependency Management

Setting up CMake and creating your first project

An introduction to CMake, the cross-platform, open-source meta-build system that solves the core challenges of C++ project management.

Why CMake?

A step-by-step guide to installing CMake. We'll explore command-line, GUI, and IDE workflows, and how to configure your compiler.

Setting Up a CMake Environment

Creating the bare minimum `CMakeLists.txt` file and build up to a project with an executable and a library, learning the fundamental commands along the way.

Writing a CMakeLists File

Learn the two-stage process of building a CMake project. This lesson covers configuring, generating, building, running, and troubleshooting common errors.

Building and Running CMake Projects

Learn how to organize large C++ projects in CMake using subdirectories and the `add_subdirectory()` command to create modular, maintainable builds.

CMake Project Structure and Subdirectories

Introducing CMake

Exploring CMake's programming features, caching mechanisms, and interactions with the file system

A primer on the fundamental building blocks of the CMake language: variables, string interpolation, and logging messages.

CMake Variables and Logging

Discover the CMake Cache, the mechanism for storing persistent user-configurable options, and learn how to create and manage cached variables.

The CMake Cache

Exploring CMake's command syntax and its list data type, including how to create, manipulate, and use lists in your projects.

CMake Commands, Arguments, and Lists

Transform your static build descriptions into dynamic scripts with CMake's control flow commands, if() and foreach().

CMake Conditionals and Loops

Exploring CMake's `file()` command, covering how to read, write, copy, and glob files, and how to manipulate paths.

Working with the File System

Learn to create reusable logic with CMake functions and macros, and how to organize them into modules for clean, scalable build systems.

Modularizing CMake Code

CMake Language and Fundamentals

Learn more about targets, and how their properties and links are the foundation of modern CMake

Learn to work with target properties - understanding their purpose, setting and updating them, and retrieving them when your build requires it

Target Properties

Learn about target types, and how the `PUBLIC`, `PRIVATE`, and `INTERFACE` keywords control how properties are shared.

Relationships Between Targets

Discover how CMake's `target_link_libraries()` command builds a dependency graph, and how it uses this graph to automatically manage transitive dependencies and link order.

Indirect Relationships and the Dependency Graph

Learn to use abstract target types like `INTERFACE`, `ALIAS`, and `IMPORTED` to model complex project needs, organize build properties, and integrate pre-compiled binaries.

Using `INTERFACE`, `ALIAS`, and `IMPORTED` Libraries

Adding support for user-configurable library types and an initial introduction to target installation.

Using Shared Libraries

Targets and Dependencies

Learn how to manage multiple build configurations within the same project, and how to create scripts that adapt to the environment

Learn how CMake manages different build configurations like Debug and Release, the difference between generator types, and how to apply settings conditionally using modern techniques.

Build Configurations (Debug, Release, etc.)

Learn the tools and patterns needed to write portable CMakeLists.txt files that work seamlessly across platforms and compilers

Cross-Platform Configurations

Learn to write architecture-aware CMake scripts for 32/64-bit systems and Apple's Universal Binaries (Intel/ARM).

Handling Different Architectures

Learn to build for different operating systems and architectures using CMake's cross-compilation support and toolchain files.

Cross-Compilation and Toolchain Files

Platforms and Build Configurations

Learn how to add external libraries to our build, and how to create our own packages for others to use

Learn to find and use pre-installed libraries with `find_package()`, understanding Module vs. Config mode and the power of imported targets

Finding Dependencies using `find_package()`

Learn how to make your libraries consumable by other projects using CMake by turning your build-tree into a distributable install-tree.

Creating a Consumable Package

Learn how to consume a CMake package you've installed, completing the producer-consumer cycle. We'll cover using `find_package()` and how to point CMake to your library's location

Using Installed Packages

Learn how to create self-contained, reproducible builds by fetching dependencies from source using `FetchContent()` and `ExternalProject_Add()`.

Fetching External Dependencies

Creating and Consuming Packages

Integrating the vcpkg and Conan package managers to handle external dependencies

Learn to manage C++ dependencies effortlessly with the vcpkg package manager and its seamless CMake integration using toolchain files and manifests.

Integrating CMake and vcpkg

Learn the day-to-day commands for managing dependencies with vcpkg and how to guarantee reproducible builds using baselines and version overrides

vcpkg Commands and Versioning

Combine vcpkg with CMake's cross-compilation capabilities. Learn to use triplets to target different architectures and chain-load toolchain files

Cross-Compiling with vcpkg

Discover Conan, the binary-first C++ package manager, and learn how to integrate it with CMake using profiles and lockfiles for fast, reproducible builds.

Using Conan with CMake

Learn to cross-compile C++ projects with Conan, using build and host profiles to manage dependencies for different platforms.

Cross-Compilation with Conan

Package Managers

Introducing presets, allowing us to simplify our workflow and share common configurations across our team

Learn the fundamentals of CMake Presets. This lesson introduces `CMakePresets.json` to simplify complex build commands.

CMake Presets

Learn to structure your CMake presets with inheritance and customize them for your local environment using `CMakeUserPresets.json`.

User Presets and Inheritance

Learn to make your CMake presets portable by using environment variables and conditional logic to adapt to different machine configurations.

Environment Variables and Conditional Presets

Learn how to extend the build process beyond simple compilation by integrating external tools and custom commands

Learn how to use generator expressions `$<...>` for build-time conditional logic.

Generator Expressions and Conditional Logic

Learn how to attach commands to specific points in a target's build lifecycle using `add_custom_command(TARGET)` for tasks like post-build file copying.

Integrating Tools with `add_custom_command()`

Learn to integrate code generators like Protobuf into your build process using `add_custom_command()`, creating automated file-level dependencies in CMake.

Generating Files with Protobuf and `add_custom_command()`

Custom Commands

An introduction to automating common workflow chores by creating custom targets

Learn to create standalone, non-code targets using add_custom_target() for utility tasks like code formatting and documentation generation.

Custom Targets and Build Utilities

Using the Clang-Format tool to automatically enforce a consistent coding style, and integrating it into our build using a custom CMake target

Using Clang-Format

An introduction to file sets and the `target_sources()` command, allowing us to manage our header files in a more controlled way

Using File Sets

A step-by-step guide to integrating Doxygen into your CMake build process for automated C++ documentation.

Generating Documentation with Doxygen

Custom Targets

Integrate automated tests into a CMake project using CTest, GoogleTest, and GoogleMock

Learn the fundamentals of automated testing in C++ with CTest. Create your first test suite, register tests with `add_test()`, and run them with the `ctest` command.

Automated Testing and CTest

Learn to refactor manual C++ tests into a professional test suite using the GoogleTest framework, managed by vcpkg and integrated with CTest.

Integrating GoogleTest with CMake

Learn to use a wide range of assertions, write data-driven parameterized tests, and isolate dependencies with Google Mock.

Assertions and Parameterized Tests

Learn how to isolate dependencies that our project uses, and then how to replace those dependencies at test time using Google Mock.

Dependency Injection and Mocking

Learn the standard pattern for testing application logic by refactoring it into a linkable library

Testing Executables

Move beyond individual tests to manage a full test suite. Learn to organize tests, run tests in parallel, filter by labels, and measure our code coverage

Managing a Test Suite

Automated Testing

Using static and dynamic analysis in CMake projects to automatically detect memory bugs, performance issues, and problematic code

Learn to find memory bugs at runtime by integrating AddressSanitizer (ASan) into a CMake project

Using AddressSanitizer (ASan)

Adding benchmarks to our build to measure the performance of our code, and track how it changes over time

Using Google Benchmark

Integrating Clang-Tidy to enforce good practices and find bugs before we even compile

Using Clang-Tidy

Automated Analysis

Automating the entire development lifecycle using Git for souce control, GitHub Actions for cloud builds, and CPack to create distributable packages and installers.

An introduction to Git, the version control system that underpins modern collaborative software development and automated build pipelines.

Source Control with Git

Learn how to automate your build and test process with Continuous Integration (CI) and a build server. This lesson provides a guide to creating a GitHub Actions workflow for a CMake project.

Build Servers and Continuous Integration

Learn to package your C++ projects using CMake's CPack. This lesson covers creating developer ZIP archives and professional Windows MSI installers with components.

Packaging with CPack

Learn to automate the packaging process by integrating CPack with a multi-platform GitHub Actions workflow

Packaging with GitHub Actions

Learn to automate the creation of a professional Windows installer by integrating CPack, the WiX Toolset, and a multi-platform GitHub Actions workflow.

Creating Installers with CPack and GitHub Actions

Learn to automate the release process using a GitHub Actions workflow that builds, packages, and publishes artifacts to a GitHub Release

Deployment with GitHub Releases

Continuous Integration and Packaging

If you have a basic grasp of C++ but find the build process intimidating, this course is for you. We assume you know the language, but not how to manage large projects.

Manage complex, cross-platform builds using industry-standard tools. Create scalable build systems that automate the entire development lifecycle.

This course is a comprehensive deep-dive into the entire C++ build ecosystem, centered around the power and flexibility of modern CMake. We leave no stone unturned.

Start with a foundational understanding of compilers, linkers, static vs. shared libraries, and object files.

The Full Build Pipeline

Learn every aspect of the CMake language, from variables and control flow to functions, modules, and generator expressions.

Complete CMake Language Mastery

Master the modern target-centric paradigm, including properties, usage requirements, and abstract targets.

Advanced Target Management

Explore every method for handling dependencies, from `find_package` and `FetchContent` to vcpkg and Conan, including versioning and cross-compilation.

In-Depth Dependency Management

Integrate a full suite of professional tools for testing (CTest, GoogleTest), analysis (ASan, Clang-Tidy), and packaging (CPack).

Total Workflow Automation

Build a fully automated deployment pipeline that takes your code from a Git push to a published GitHub Release with multi-platform installers.

End-to-End CI/CD and Deployment

What You'll Learn

Become a software engineer with C++.  Starting from the basics, we guide you step by step along the way

Intro to C++ Programming

If you're completely new to programming or want a thorough introduction, consider starting with our free introductory course:

New to Programming?

Managing C++ Projects Using CMake

In our last lesson, we saw how the linker takes our scattered collection of object files (`.o` or `.obj`) and stitches them together into an executable. We learned that the linker's main job is resolving symbols - connecting function calls to their definitions across different files.


We briefly touched on the idea of linking against a **library**, an archive of pre-compiled object files. This is how we use code from external sources like the C++ Standard Library without having to compile it ourselves every time.


Now, we'll introduce the two fundamental types of libraries in the C++ world: _**static libraries**_ and _**dynamic (or shared) libraries**_. By the end of this lesson, you'll know what `.a`, `.lib`, `.so`, and `.dll` files are, how they're created and used, and the trade-offs that will guide your choice between them.


The process of creating and linking libraries is demonstrated manually on the command line in this lesson.  This is tedious and error-prone, but don't be discouraged by these examples.


Eventually, CMake will be taking care of these low-level mechanics for us.  The most important thing to get from this lesson is the conceptual difference between static and dynamic libraries.


## Creating and Using Static Libraries


Let's start with the simpler of the two: the static library. As we learned previously, static linking involves copying all the required code from object files and libraries directly into your final executable at build time. The result is a single, self-contained program.


A **static library** is essentially just a package - an archive - of object files. On Unix-like systems (Linux, macOS), they have a `.a` (for "archive") extension. On Windows, they typically use `.lib`.


### Why Bother with Static Libraries?


You might wonder, if a static library is just a bag of object files, why not just give all the object files to the linker directly? For a small project, you could. But imagine a library with hundreds of source files. Your link command would become enormous and unmanageable:


```c++
//<ti>
g++ main.o app.o ui.o network.o logger.o math.o ... (100 more .o files) ... -o my_app
```


A static library cleans this up. You bundle all those object files into a single library file, say `libutils.a`, and your link command becomes much simpler.  The command might look something like the following, which we'll break down in the next section:


```javascript
//<ti>
g++ main.o -L. -lutils -o my_app
```


### How to Create a Static Library


Creating a static library is a two-step process:

1. **Compile**: Compile all your library's source files into object files.
2. **Archive**: Use a special tool called an archiver to bundle the object files into a single library file.

Let's create a small utility library with a logger and a math function.


<CodeViewer>


<CodeFile path="logger.h" status="New">


```c++
#pragma once

#include <string>

void log_message(const std::string& msg);
```


</CodeFile>


<CodeFile path="logger.cpp" status="New">


```c++
#include "logger.h"
#include <iostream>

void log_message(const std::string& msg) {
  std::cout << "[LOG]: " << msg << std::endl;
}
```


</CodeFile>


<CodeFile path="math_utils.h" status="New">


```c++
#pragma once

int add(int a, int b);
```


</CodeFile>


<CodeFile path="math_utils.cpp" status="New">


```c++
#include "math_utils.h"

int add(int a, int b) {
  return a + b;
}
```


</CodeFile>


</CodeViewer>


### Compiling to Object Files


We use the `-c` flag to tell the compiler to stop after producing object files and not to proceed with linking.


```c++
//<ti>
g++ -c logger.cpp -o logger.o
```


```c++
//<ti>
g++ -c math_utils.cpp -o math_utils.o
```


Now we have `logger.o` and `math_utils.o`.


### Archive the Object Files


To create the library, we use the `ar` (archiver) command:


```javascript
//<ti>
ar rcs libutils.a logger.o math_utils.o
```


The `rcs` flags mean:

- `r` - replace older files in the archive
- `c` - create the archive if it doesn't exist
- `s` - write an object-file index into the archive.  This index just makes it faster for the linker to find symbols that our code is trying to use.

We've now created `libutils.a`. If you're using the Visual Studio toolchain, you'd use [lib.exe](https://learn.microsoft.com/en-us/cpp/build/reference/lib-reference?view=msvc-170) instead of `ar`.


<Img hasTransparency invertible file="cmake-archiving-2.png" alt="Diagram showing the archiving process" width="1200" height="576" blurHash="L14B,y~q4n00-;xuRjM{9F%MayM{" />


<Pw>


## How to Use a Static Library


Now let's write a `main.cpp` that uses our new library and link it.  Alongside our precompiled library, we'd also share the header files describing what is in the library.


Then, developers can use our library in the same way they'd use code they wrote themselves.  They'd just `#include` the relevant headers and use the symbols they declare:


<CodeFile path="main.cpp" status="New">


```c++
#include "logger.h"
#include "math_utils.h"
#include <iostream>

int main() {
  log_message("Starting program.");
  int result = add(5, 7);
  std::cout << "5 + 7 = " << result;
  return 0;
}
```


</CodeFile>


First, let's compile `main.cpp` to an object file:


```c++
//<ti>
g++ -c main.cpp -o main.o
```


Now, we'll link `main.o` with our static library `libutils.a`:


```c++
//<ti>
g++ main.o -L. -lutils -o my_app
```


Let's break down those linker flags:

- `L.` tells the linker to look for library files in the current directory (`.`). You can provide any path here, like `-L/path/to/libs`.
- `lutils` tells the linker to find and link a library named `utils`. The linker automatically prepends `lib` and appends `.a` (or `.so`, as we'll see) to the name. So `-lutils` becomes a search for `libutils.a`.

The linker now resolves the undefined symbols `log_message` and `add` from `main.o` by looking inside `libutils.a`. It finds the definitions in `logger.o` and `math_utils.o` within the archive, _**copies their machine code into**_ _**`my_app`**_, and produces the final executable.


The resulting `my_app` is completely self-contained. You can delete `libutils.a`, `main.o`, `logger.o`, and `math_utils.o`, and `my_app` will still run perfectly. All the necessary code is baked in:


```c++
//<ti>
./my_app.exe
```


```c++
//<o>
[LOG]: Starting program.
5 + 7 = 12
```


## Dynamic Libraries and Runtime Linking


Static libraries are simple and robust, but they have a few major drawbacks. Every program that uses a static library gets its own copy of the code, which can waste disk space and memory.


<Img hasTransparency invertible file="cmake-static-libs.png" alt="Diagram showing static linking" width="1200" height="769" blurHash="L3FiPxof00ay4nof00ay00WB~qj[" />


And if you need to update the library (e.g., to fix a bug), you have to re-link and redistribute every single application that uses it.


**Dynamic libraries** solve these problems. They are also known as **shared libraries** because their main benefit is that they can be _shared_ by multiple running programs. On Linux/macOS, they are `.so` (Shared Object) files. On Windows, they are the famous `.dll` (Dynamic Link Library) files.


### How Dynamic Linking Works


Unlike static linking, dynamic linking defers most of the work until **runtime**.


**At Link Time:** When you link your program against a dynamic library, the linker _**does not copy the library's code**_. Instead, it places a small placeholder (a stub) in your executable. This stub essentially says, "When this program runs, it will need the function `connect()` from the library `Network.dll`". The executable is now much smaller, but it has an external dependency.


**At Run Time:** When you execute your program, the operating system's **dynamic linker** (or loader) kicks in. It reads the list of dependencies from your executable, finds the required `.so` or `.dll` files on your system, and loads them into memory. It then performs the final symbol resolution and relocation on the fly, patching your program's function calls to point to the correct addresses in the newly loaded library code.


If multiple programs using `Network.dll` are running, the OS is smart enough to load only one copy of `Network.dll` into physical memory and share it among all of them, saving a significant amount of RAM.


<Img hasTransparency invertible file="cmake-dynamic-libs.png" alt="Diagram showing dynamic linking" width="1200" height="767" blurHash="L3CP@efQ00j[~qj[-;ay00ay?bj[" />


## Creating a Dynamic Library


The process is similar to creating a static library, but with two key differences in the compilation and linking commands.


### Compile with Position-Independent Code (PIC)


Because a shared library can be loaded at any address in memory by the OS, its code cannot rely on absolute memory addresses. It must be written in a way that it can run regardless of where it's placed. This is called **Position-Independent Code**, or PIC.


We tell the compiler to generate this with the `-fPIC` flag:


```javascript
//<ti>
g++ -c -fPIC logger.cpp -o logger.o
```


```c++
//<ti>
g++ -c -fPIC math_utils.cpp -o math_utils.o
```


### Link into a Shared Library


Instead of using `ar`, we use the compiler/linker again, but this time with the `-shared` flag to tell it to produce a shared library instead of an executable.


```javascript
//<ti>
g++ -shared logger.o math_utils.o -o libutils.so
```


For Windows, we'd use a `.dll` extension instead of `.so`:


```c++
//<ti>
g++ -shared logger.o math_utils.o -o libutils.dll
```


We now have our shared library ready to use - `libutils.so` or `libutils.dll`.


### Using a Dynamic Library


Linking against it looks identical to the static library case:


```javascript
//<ti>
g++ main.o -L. -lutils -o my_app
```


Most linkers, when given the choice between `libutils.a` and `libutils.so` in the same directory, will prefer the shared version by default.


We've now created our `my_app` executable, and it should be smaller than our previous version that included the contents of the static library.  We can try to run it:


```javascript
//<ti>
./my_app
```


On Windows, this is likely to work.  Windows checks the directory containing the executable for any `dll` files it requires.  So, as long as our `dll` is in the same directory, Windows will find it, and our program will run successfully:


```c++
//<o>
[LOG]: Starting program.
5 + 7 = 12
```


However, on Unix-like systems, we may have gotten an error similar to this:


```javascript
//<oe>
./my_app: error while loading shared libraries: libutils.so: cannot open shared object file: No such file or directory
```


**What happened?** The program started, the OS loader saw it needed `libutils.so`, but it didn't know where to find it. The OS only looks in a few standard system directories by default (like `/usr/lib` on Linux).


We'll see more robust ways to solve this later but, for now, you can tell the loader where to look using the `LD_LIBRARY_PATH` environment variable.  We'll set it to `.`, indicating the current directory, thereby replicating Windows' behaviour:


```javascript
//<ti>
export LD_LIBRARY_PATH=.
```


Our program should now work:


```javascript
//<ti>
./my_app
```


```javascript
//<o>
[LOG]: Starting program.
5 + 7 = 12
```


Managing these paths and cross-platform differences for deployment is a major challenge that build systems like CMake help solve, often by embedding the library search path directly into the executable using a mechanism called `rpath`.  We'll cover this in detail later.


# Static vs. Dynamic Linking


Choosing between static and dynamic linking involves a series of trade-offs. There is no single "best" answer; the right choice depends entirely on your project's needs.


| **Feature**             | **Static Linking**                                                              | **Dynamic Linking**                                                                 |
| ----------------------- | ------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------- |
| **Executable Size**     | **Larger**. All library code is copied into the final executable.               | **Smaller**. The executable only contains stubs and references to the library.      |
| **Deployment**          | **Simpler**. Distribute a single file. No dependency issues.                    | **More Complex**. Must distribute the executable _and_ all required .dll/.so files. |
| **Memory Usage**        | **Higher**. Each running program has its own copy of the library in memory.     | **Lower**. The OS loads one copy of the library and shares it among all programs.   |
| **Updates/Maintenance** | **Harder**. To update a library, every application using it must be re-linked.  | **Easier**. Update a bug-fixed library by just replacing the .so/.dll file.         |
| **Startup Performance** | **Slightly Faster**. No runtime work needed to find and load libraries.         | **Slightly Slower**. The OS loader must find, load, and link libraries on startup.  |
| **Link Time**           | **Slower**. The linker has more work to do, copying code and resolving symbols. | **Faster**. The linker just creates stubs, deferring most work to runtime.          |


<Aside>


### The Dreaded "DLL Hell"


A classic problem with dynamic linking is "DLL Hell", or "dependency hell". This happens when multiple applications on a system rely on different, incompatible versions of the same shared library.


For example, `App_A` needs `libcool.so` version 1.0. You then install `App_B`, which overwrites the system's `libcool.so` with version 2.0. If version 2.0 isn't backward-compatible, `App_A` suddenly breaks.


Static linking completely avoids this problem because each application is bundled with the exact version of the library it was built with.


While modern package managers and application containerization have helped mitigate DLL Hell, it's a fundamental risk of a shared-dependency model.


</Aside>


# Summary


We've covered the core concepts of C++ libraries, a foundational topic for building any non-trivial application.

- **Static Libraries (****`.a`****,** **`.lib`** **files)**: These are archives of object files. When you link against them, their code is **copied** into your executable at build time. This creates a large, self-contained program that's easy to deploy but inefficient in memory and difficult to update.
- **Dynamic/Shared Libraries (****`.so`****,** **`.dll`** **files)**: These are standalone files that are **loaded at runtime**. Your executable is smaller and only contains references. This model saves memory and makes updates easy, but complicates deployment as you must ship the library files alongside your executable.
- **The Process**: We saw the command-line tools (`ar`, `g++ -shared`, `-fPIC`) for creating both types of libraries and the linker flags (`-L`, `-l`) for using them.

Ultimately, the choice between static and dynamic linking is a design decision. Do you want a simple, standalone executable? Use static linking. Are you building a large system with shared components or need to be able to patch libraries without a full redeployment? Dynamic linking is your friend.


In the upcoming chapters, we will see how CMake abstracts away the platform-specific commands and makes creating, finding, and linking both static and dynamic libraries a simple, portable, and elegant process.


</Pw>

Fixed typo in archiving diagram, and minor presentation issue

Preprocessor Directives and the Build Process

Internal and External Linkage

C++20 Modules

Static library

Dynamic-link library

Create and use a static library

Create and use your own Dynamic Link Library (C++)

Static and Dynamic Libraries | Set 1

Understanding shared libraries in Linux

What is the difference between a static library and a dynamic library?

Position-independent code

STATIC vs DYNAMIC LIBRARIES in C++

{CPP}A comprehensive guide to C++ libraries. Understand how to create and use static libraries (.a, .lib) and shared/dynamic libraries (.so, .dll), and learn the key trade-offs between them in terms of executable size, deployment, and performance.

{CPP}C++ Static vs. Dynamic Libraries: Creating and Using .a, .lib, .so, and .dll Files

Compile with Position-Independent Code (PIC)

Static and Shared Libraries

Understanding the Basics

Practical Applications

Common Mistakes

Next Steps

Additional Resources

Assessment Preparation

Managing C++ Projects Using CMake