contact@linuxtpoint.com
Linuxtpoint
Candid photograph of a Linux server terminal with a soft olive-green glow against a dark slate background, conveying a calm technical atmosphere.

Step-by-step guides for system administrators — covering command-line basics, web server setup, and preparation material for technical interviews.

Browse Tutorials

How to Compile and Install Software from Source on Fedora

Fedora’s repositories cover most everyday applications, but administrators sometimes need a newer release, an optional feature, or software that has not yet been packaged. Building from source provides that control, provided the system has the correct compiler, libraries, and installation path.

This workflow suits Fedora Workstation, Fedora Server, and related Red Hat-based systems. It also applies to many projects distributed as tarballs with a configure script, CMake files, Meson definitions, or a hand-written Makefile.

Australian users may notice that large source archives download at different speeds depending on the mirror selected. A developer in Sydney, Brisbane, or Perth can usually improve transfer times by choosing a nearby Fedora mirror, although a fast NBN connection will often make the difference less noticeable.

The commands below install locally under /usr/local rather than replacing Fedora-managed files. That separation makes upgrades safer and gives administrators a clear way to identify software compiled manually.

Installation method Typical location Update handling Best suited to
Fedora RPM package /usr, /etc Managed by DNF Stable production systems
Source with /usr/local /usr/local Manual Custom versions and features
Source-built RPM RPM database paths DNF-compatible Repeatable server deployments
User-local build Home directory Manual Testing without root access

Prepare Fedora for a source build

Refresh repository metadata and install the standard development toolchain:

sudo dnf upgrade --refresh
sudo dnf group install "Development Tools"
sudo dnf install gcc-c++ cmake meson ninja-build pkgconf-pkg-config \
  openssl-devel zlib-devel tar curl git

A project may require different development headers. For example, graphical applications can need GTK or Qt packages, while network services commonly need OpenSSL, cURL, SQLite, or compression libraries. Read the project’s Fedora, RHEL, or build-dependency documentation before compiling.

Keep source archives in a dedicated directory and inspect the project’s release notes. For a regular workstation in Melbourne or Adelaide, downloading during a quieter evening period can avoid congestion on shared office or household connections.

Useful checks before compiling:

Download and inspect the source

Use the project’s official release page, Git repository, or signed distribution archive. Avoid compiling an untrusted copy simply because it appears in a search result. A typical archive workflow looks like this:

mkdir -p ~/src
cd ~/src
curl -LO https://example.org/software-2.4.1.tar.xz
curl -LO https://example.org/software-2.4.1.tar.xz.sha256
sha256sum -c software-2.4.1.tar.xz.sha256
tar -xf software-2.4.1.tar.xz
cd software-2.4.1

Check the extracted files with ls, README, INSTALL, and CONTRIBUTING documents. Confirm the licence before deploying the result in an Australian business or government environment; Linuxtpoint’s copyright policy provides useful guidance about responsible publication and reuse of technical material.

Git projects require a slightly different approach:

git clone https://github.com/example/project.git
cd project
git checkout v2.4.1

A tagged release is usually more predictable than compiling the newest development branch. Record the commit ID or archive checksum so another administrator can reproduce the same build.

Configure and compile the program

Traditional Autotools projects generally use this sequence:

./configure --prefix=/usr/local/software-2.4.1
make -j"$(nproc)"
make check

The --prefix option places the application in its own directory. If configuration stops with a missing header, search Fedora packages with dnf provides, then install the matching -devel package. For example, a missing openssl/ssl.h normally points to openssl-devel, not the runtime OpenSSL package.

CMake and Meson builds should use a separate build directory so the source tree remains clean:

cmake -S . -B build -DCMAKE_BUILD_TYPE=Release \
  -DCMAKE_INSTALL_PREFIX=/usr/local/software-2.4.1
cmake --build build --parallel
ctest --test-dir build

For Meson, use meson setup build --prefix=/usr/local/software-2.4.1, followed by ninja -C build and ninja -C build test. Projects with mobile or graphical components may have unusual build steps; an example such as animated splash screens illustrates why project-specific assets and toolchains should be checked rather than assumed.

Install without creating package conflicts

Install only after the tests pass:

sudo cmake --install build

For an Autotools project, the equivalent is commonly sudo make install. Never run the build itself as root. If the software installs shared libraries, add its library directory through /etc/ld.so.conf.d/software.conf and run sudo ldconfig; otherwise, use the application’s documented runtime path.

For server fleets, a source-built RPM is preferable to an untracked make install. Fedora packaging tools can create a package with a spec file, allowing installation, removal, and inventory through DNF. This approach is particularly useful for Australian organisations managing separate Sydney and Perth systems where consistent deployment matters.

Add a small environment file instead of editing shell configuration randomly:

echo 'export PATH=/usr/local/software-2.4.1/bin:$PATH' \
  | sudo tee /etc/profile.d/software.sh

Verify and maintain the installation

Confirm the binary location and version:

command -v software
software --version
rpm -qf "$(command -v software)" || true

The last command may report that the file is not owned by an RPM, which is expected for a direct /usr/local installation. Keep the original archive, checksum, build options, compiler version, and dependency list in an administrator’s record.

For broader Linux administration reference, the Linux and Unix guides offer related command-line and system-maintenance material. When a new upstream release arrives, compile it in a new versioned directory, test it, switch the service or symlink, and retain the previous build until the replacement has been verified.

On a test Fedora host, create ~/src, download one signed release archive, verify its checksum, and run its documented configuration command before installing anything system-wide.