How To Install Pangolin on Fedora 44

Install Pangolin on Fedora 44

If you have ever tried to build ORB-SLAM2 or a custom computer vision pipeline on Fedora, you already know the pain: Pangolin is not in any official RPM repository, and the build process requires a specific sequence to work correctly. One missed dependency or skipped step, and CMake silently drops features without telling you why.

This guide gives you the complete, tested process to install Pangolin on Fedora 44 from source. Every command is explained, not just listed. By the end, you will have a fully functional Pangolin installation that other CMake-based projects on your system can detect automatically with find_package().

Fedora 44 ships with GCC 16, DNF5, and LLVM 22, which makes it one of the most capable Linux distributions for C++ development right now. That said, the modern toolchain introduces a few quirks worth knowing about, and this guide covers those too.

Prerequisites

Before you start, confirm these items are in place:

  • Operating system: Fedora Linux 44 (fully updated; both Workstation and Server editions work)
  • User privileges: A non-root user account with sudo access
  • Internet connection: Required to pull packages via DNF and clone from GitHub
  • Terminal access: You will run all commands from a Bash terminal
  • Disk space: At least 2 GB free in your home directory for the source tree and build artifacts
  • RAM: 2 GB minimum; 4 GB or more is strongly recommended because compiling C++ libraries is memory-intensive

No prior experience with CMake is required. Each step explains what is happening under the hood so you can follow along even if this is your first time building software from source on Linux.

What Is Pangolin and Why Does It Not Come Pre-Installed?

Pangolin is a lightweight, portable C++ utility library built by Steven Lovegrove for prototyping 3D, numeric, and video-based programs. It handles OpenGL display management, viewport interaction, video input abstraction, and provides a built-in drop-down Python console for live tweaking and scripting.

It has become a standard dependency in the computer vision and robotics research community, used heavily with ORB-SLAM2, ORB-SLAM3, and Meta’s projectaria_tools. The reason Pangolin does not ship with Fedora is scope: Fedora’s maintainers focus on broadly applicable libraries, and Pangolin is specialized enough to fall outside standard repository inclusion criteria.

The library is MIT licensed and actively maintained on GitHub with 2,600+ stars, 70 contributors, and 8 stable releases, the latest being v0.9.4 as of October 2025. You build it yourself, which is straightforward once you know the correct sequence.

Step 1: Update Your Fedora 44 System

The very first action before touching any build dependency is a full system update.

sudo dnf upgrade --refresh -y

What this does: dnf upgrade updates every installed package to its latest version. The --refresh flag forces DNF5 to sync package metadata from all configured repositories before resolving anything, bypassing any stale local cache. The -y flag auto-confirms the transaction.

Why this matters: Fedora 44 uses GCC 16 as its default C++ compiler. If your system has partially updated runtime libraries from a previous GCC version, CMake can link against mismatched headers and produce a broken build that is very difficult to debug. Starting from a clean, fully upgraded baseline eliminates this class of problem entirely.

After the upgrade completes, if a new kernel was installed, reboot before continuing:

sudo reboot

This ensures you are running on the correct kernel matching your updated driver stack, which is especially important if you have a dedicated NVIDIA or AMD GPU.

Step 2: Install Required Build Dependencies via DNF

Pangolin’s build system auto-detects which features to include based on what libraries it finds on your system. A missing development package does not cause a build failure; it just silently disables that feature. The problem is you may not realize key functionality is missing until much later when something downstream breaks.

Install everything upfront so your build is complete from the start:

sudo dnf install -y \
  git cmake ninja-build gcc-c++ \
  mesa-libGL-devel glew-devel \
  eigen3-devel libpng-devel libjpeg-devel \
  ffmpeg-devel python3-devel python3-pip \
  doxygen

Here is why each package group belongs in this list:

  • git — You need Git to clone the repository with submodule support. Without it, there is no source code to build.
  • cmake — Pangolin uses CMake as its build configuration system. CMake generates compiler instructions tailored to your specific hardware and library setup.
  • ninja-build — An alternative build executor to GNU Make. Ninja schedules parallel compilation jobs automatically, cutting build times significantly on multi-core CPUs. On a 4-core machine it can reduce compile time by 50% or more compared to a single-threaded Make run.
  • gcc-c++ — Pangolin is written in C++. The base gcc package covers C only; gcc-c++ adds the C++ standard library headers and the g++ front-end that CMake requires to compile .cpp files.
  • mesa-libGL-devel and glew-devel — Pangolin’s entire rendering pipeline runs on OpenGL. Mesa provides the base OpenGL interface and development headers. GLEW (the GL Extension Wrangler Library) handles runtime detection of OpenGL extensions so Pangolin works portably across AMD, Intel, and NVIDIA hardware.
  • eigen3-devel — Eigen is a C++ linear algebra library. Pangolin uses it for camera model math and 3D coordinate transforms. These are compile-time headers, so you need the -devel variant.
  • libpng-devel and libjpeg-devel — Image I/O backends for Pangolin’s texture loading system. Without these, you cannot display images in Pangolin windows or capture screenshots.
  • ffmpeg-devel — Required for Pangolin’s video input and output support. If this package is absent, all video stream features are silently dropped during the CMake configure step.
  • python3-devel and python3-pip — Needed only if you want the pypangolin Python bindings, which let you drive Pangolin visualizations from Python scripts using the same C++ API.
  • doxygen — Optional but useful for generating Pangolin’s HTML documentation locally if you prefer browsing it offline.

After installation, verify the key compiler tools are accessible:

gcc --version
cmake --version
ninja --version

Expected output looks something like:

gcc (GCC) 16.x.x
cmake version 3.30.x
1.12.x

The exact minor versions matter less than confirming these commands exist and respond without errors.

Step 3: Clone the Pangolin Repository

Move to a directory where you want to keep the source code. Your home directory or a dedicated ~/code folder both work:

mkdir -p ~/code && cd ~/code
git clone --recursive https://github.com/stevenlovegrove/Pangolin.git
cd Pangolin

What --recursive does: Pangolin uses Git submodules for some of its optional components. This flag tells Git to initialize and clone all declared submodules along with the main repository in a single pass.

Why this flag is critical: If you clone without --recursive, the submodule directories exist in the file tree but are completely empty. When CMake later tries to include headers from those directories, you get cryptic No such file or directory errors that look like a broken dependency install even when everything is actually in place.

The fix is running git submodule update --init --recursive inside the repo, but it is much cleaner to get it right from the start. Take a moment to verify the repo structure:

ls

You will see key directories including src/ (core library source), components/ (modular feature backends), scripts/ (dependency helpers), and examples/ (working demo programs).

Step 4: Run the Pangolin Prerequisite Script

Pangolin ships a smart shell script that auto-detects your Linux distribution’s package manager and generates the correct package names for your specific system.

Start with a dry run to review what it plans to install:

./scripts/install_prerequisites.sh --dry-run recommended

Why run the dry run first: The script auto-detects DNF on Fedora and maps Pangolin’s dependency list to the correct Fedora package names. Some names differ from what Ubuntu-focused documentation shows. Reviewing the output before accepting lets you catch anything unexpected.

Once you are satisfied with the package list, run it for real:

./scripts/install_prerequisites.sh recommended

The recommended argument installs everything needed for a feature-complete Pangolin build. You can also pass required for a bare-minimum build or all to include experimental video backends. For most users, recommended is the right choice.

Step 5: Configure the Pangolin on Fedora 44 Setup with CMake

This step is where CMake scans your system, detects all available libraries, and generates the build instructions for Ninja. Run this from inside the Pangolin directory:

cmake -B build -G Ninja -DCMAKE_BUILD_TYPE=Release

Breaking down each flag:

  • -B build — Tells CMake to create and use a subdirectory called build/ for all output files. This is called an out-of-source build. It keeps compiled objects, generated headers, and CMake’s cache files completely separate from the source tree. If something goes wrong, you delete build/ and start fresh without touching a single source file.
  • -G Ninja — Instructs CMake to generate Ninja build files instead of the default GNU Makefiles. Ninja’s dependency tracking is faster and its output is cleaner to read during compilation.
  • -DCMAKE_BUILD_TYPE=Release — Compiles with full compiler optimizations enabled. Use Debug only if you are actively developing Pangolin itself; Release is correct for all normal usage.

Reading the CMake output carefully: As CMake runs, it prints Found and NOT FOUND lines for each dependency it checks. The lines you want to see are:

-- Found OpenGL: ...
-- Found GLEW: ...
-- Found Eigen3: ...
-- Found JPEG: ...
-- Found PNG: ...

If you see NOT FOUND for OpenGL or GLEW, stop here. Go back to Step 2 and verify mesa-libGL-devel and glew-devel are installed correctly. Every NOT FOUND line means a Pangolin feature is disabled in your build without any further warning.

Step 6: Build Pangolin

With the build files generated, compile the library:

cmake --build build

What happens here: CMake hands off execution to Ninja, which reads the generated build plan and compiles all .cpp files in parallel. You will see a percentage counter climbing in the terminal as each source file is compiled.

Why the two-step approach (configure, then build) is the right way to work with CMake: If a configure error occurs mid-stream, separating these steps means you catch it before spending CPU cycles on compilation. A combined command would leave partial build artifacts that confuse subsequent runs.

The build typically takes 3 to 8 minutes depending on your CPU and available RAM. On a modern 8-core machine with Ninja, expect closer to 3 minutes.

If you hit this specific error during the build:

fatal error: GL/glew.h: No such file or directory

This means CMake did not detect glew-devel during configuration. The fix requires a clean rebuild:

sudo dnf reinstall glew-devel
rm -rf build/
cmake -B build -G Ninja -DCMAKE_BUILD_TYPE=Release
cmake --build build

Always delete build/ when fixing missing headers. CMake caches negative detection results and will not re-check unless you force a full re-scan.

Step 7: Install Pangolin System-Wide and Run ldconfig

Once the build completes without errors, install the library:

sudo cmake --install build

What this installs and where:

  • Shared library files (libpangolin.so) go to /usr/local/lib/
  • Header files go to /usr/local/include/pangolin/
  • CMake config files go to /usr/local/lib/cmake/Pangolin/

Why sudo is required: The default install prefix is /usr/local, which is owned by root on Fedora. This is the correct location for manually compiled system libraries.

Why the CMake config files matter most: The PangolinConfig.cmake file installed under /usr/local/lib/cmake/Pangolin/ is what enables other projects to find Pangolin automatically using find_package(Pangolin REQUIRED). Without it, every downstream project needs hardcoded library paths that break when directories change.

After installation, refresh the dynamic linker’s library cache:

sudo ldconfig

Why this step is mandatory: Linux’s dynamic linker maintains a cache of known shared libraries. When you add a new .so file to /usr/local/lib/, the linker does not automatically know it exists. Running ldconfig rebuilds that cache. Skip it and you will get symbol lookup error messages when running any program linked against Pangolin.

Verify the installation registered correctly:

ldconfig -p | grep pangolin

You should see:

libpangolin.so.0 (libc6,x86-64) => /usr/local/lib/libpangolin.so.0

Step 8: (Optional) Install pypangolin Python Bindings

If you work with Python and want to drive Pangolin visualizations from scripts, build and install the pypangolin module:

cmake --build build -t pypangolin_pip_install

What this does: CMake runs a custom target that builds a pybind11-generated Python wheel and installs it into your active Python 3 environment via pip. After this step, import pangolin works in any Python script.

Verify it loaded correctly:

python3 -c "import pangolin; print('pypangolin loaded successfully')"

If you get ModuleNotFoundError, confirm that the Python version CMake found during the Step 5 configure phase matches the Python version you are currently running. Scroll back through the CMake output and look for a line like Selected Python: '/usr/bin/python3.13'. You can override it explicitly during configure:

cmake -B build -G Ninja -DPython3_EXECUTABLE=$(which python3)

Step 9: Verify the Full Installation with Tests

Run the built-in test suite to confirm everything works end to end:

cmake -B build -G Ninja -DBUILD_TESTS=ON
cmake --build build
cd build && ctest

Why running tests matters beyond just a successful compile: A successful compile only proves the source code was syntactically correct and that the linker found the right libraries. It does not prove that an OpenGL rendering context can actually initialize on your GPU and driver combination.

If TestDisplay fails, this almost always means your system is running headless (a server without a GPU, or an SSH session without X forwarding). That failure does not affect non-display uses of Pangolin; all other tests passing is a good result.

For a quick sanity check on a workstation with a display attached, run one of the bundled examples:

./build/examples/SimpleDisplay/SimpleDisplay

A window with a colored triangle and Pangolin’s panel UI should open. If it does, your configure Pangolin on Fedora 44 process is complete.

How To Use Pangolin in Your Own CMake Project

Once Pangolin is installed system-wide, linking against it in your own project takes just a few lines in your CMakeLists.txt:

cmake_minimum_required(VERSION 3.16)
project(MyVisionApp)

find_package(Pangolin REQUIRED)

add_executable(my_app main.cpp)
target_link_libraries(my_app ${Pangolin_LIBRARIES})
target_include_directories(my_app PUBLIC ${Pangolin_INCLUDE_DIRS})

find_package(Pangolin REQUIRED) works because the sudo cmake --install step placed PangolinConfig.cmake under /usr/local/lib/cmake/Pangolin/. CMake searches that prefix automatically.

The ${Pangolin_LIBRARIES} and ${Pangolin_INCLUDE_DIRS} variables are populated by that config file and expand to the exact paths on your system. This is the same pattern that ORB-SLAM2 and projectaria_tools use to link against Pangolin in production research codebases.

Troubleshooting Common Errors When You Install Pangolin on Fedora 44

Even with a careful setup, a handful of errors appear consistently. Here are the five most common ones with their root causes and exact fixes.

Error 1: GL/glew.h: No such file or directory

Cause: glew-devel was not installed, or CMake did not detect it during configuration.

sudo dnf install glew-devel
rm -rf build/
cmake -B build -G Ninja -DCMAKE_BUILD_TYPE=Release
cmake --build build

Always delete build/ after fixing a missing header package. CMake caches NOT FOUND results and will not re-check unless forced.

Error 2: Could NOT find Eigen3 (missing: Eigen3_DIR)

Cause: eigen3-devel is not installed, or CMake cannot locate the Eigen3 config file.

sudo dnf install eigen3-devel

If the problem continues after reinstalling, find the config file and pass its path explicitly:

find /usr -name "Eigen3Config.cmake" 2>/dev/null
cmake -B build -G Ninja -DEigen3_DIR=/path/you/found

Error 3: Empty Submodule Directories After Clone

Cause: The repo was cloned without --recursive.

cd ~/code/Pangolin
git submodule update --init --recursive

Re-run the CMake configure step after this completes.

Error 4: symbol lookup error: libpangolin.so.0: undefined symbol

Cause: ldconfig was not run after installation, so the dynamic linker cache is stale.

sudo ldconfig

If the error continues, verify the library file exists:

ls /usr/local/lib/libpangolin*

If no files appear, re-run sudo cmake --install build.

Error 5: SELinux Blocks Pangolin at Runtime

Cause: Fedora 44 runs SELinux in enforcing mode by default. Shared libraries placed in /usr/local/lib/ by a manual install may lack the correct SELinux security context labels.

Symptom: Programs that link against Pangolin fail with Permission denied at runtime even though file permissions look correct.

sudo ausearch -m avc -ts recent

If you see AVC denial entries referencing libpangolin.so, apply the correct labels:

sudo restorecon -Rv /usr/local/lib/
sudo restorecon -Rv /usr/local/include/

This re-labels the installed files to match Fedora’s SELinux policy for shared libraries.

Congratulations! You have successfully installed Pangolin. Thanks for using this tutorial for installing the Pangolin on Fedora 44 Linux system. For additional help or useful information, we recommend you check the official Pangolin website.

VPS Manage Service Offer
If you don’t have time to do all of this stuff, or if this is not your area of expertise, we offer a service to do “VPS Manage Service Offer”, starting from $10 (Paypal payment). Please contact us to get the best deal!
r00t is a Linux Systems Administrator and open-source advocate with over ten years of hands-on experience in server infrastructure, system hardening, and performance tuning. Having worked across distributions such as Debian, Arch, RHEL, and Ubuntu, he brings real-world depth to every article published on this blog. r00t writes to bridge the gap between complex sysadmin concepts and practical, everyday application — whether you are configuring your first server or optimizing a production environment. Based in New York, US, he is a firm believer that knowledge, like open-source software, is best when shared freely.

Related Posts