You cloned a repo and the compiler is missing
You pulled a project from GitHub, opened a terminal, and ran make. The shell immediately replied with gcc: command not found. You installed Fedora Workstation expecting a capable development environment, but the default image ships with a clean desktop, not a compiler suite. You need the toolchain before you can compile anything.
What DNF groups actually do
Fedora separates base system packages from development toolchains to keep the default install lean and secure. The Development Tools group is a meta-package that pulls in the GNU Compiler Collection, build automation tools, debuggers, and autotools. Think of it like a pre-assembled mechanic's toolbox. You do not need every wrench on day one, but when you start taking apart a car, having the standard set saves you from hunting for individual parts.
DNF groups are just collections of package names bundled under a single identifier. When you install a group, DNF resolves all the dependencies and installs them in one transaction. The group definition lives in the repository metadata, not on your disk. You can inspect it before committing, which prevents surprise disk usage and dependency conflicts.
Run dnf groupinfo first. Read the package list before you type sudo.
Install the base toolchain
Here is how to inspect the group and install it in one controlled workflow.
# Show exactly which packages belong to the group before installing
dnf groupinfo "Development Tools"
The output lists every compiler, linker, debugger, and build helper that will land on your system. If you see packages you do not recognize, check their descriptions with dnf info <package>. DNF groups are curated by the Fedora Packaging Committee, so every package there serves a documented purpose.
# Install the entire toolchain group with root privileges
sudo dnf groupinstall "Development Tools"
# --refresh forces DNF to fetch fresh metadata from the mirrors
# This prevents stale group definitions from causing missing packages
Fedora mirrors update continuously. Running dnf upgrade --refresh weekly keeps your metadata current and avoids group definition drift. The --refresh flag is standard practice before any group operation or major package pull.
# Verify that the transaction completed without dependency resolution errors
sudo dnf check
The dnf check command scans your installed database for broken dependencies or conflicting files. A clean exit means your toolchain is ready. Reboot is not required for compiler installs, but a fresh shell session clears any cached PATH variables.
Run dnf check after every group install. Catch broken dependencies before you start compiling.
Verify the installation
Compilers and build tools do not announce themselves on install. You must query them directly to confirm they are on your PATH and functioning.
# Check the GCC C compiler version and target architecture
gcc --version
# Check the G++ C++ compiler version
g++ --version
# Verify the GNU Make build automation tool
make --version
Each command should print a version string followed by the target triplet, such as x86_64-redhat-linux-gnu. If you see command not found, your shell is not sourcing /usr/bin correctly, or the installation failed silently due to a disk quota or SELinux context mismatch. Check your journal before assuming the package is missing.
# Review recent DNF transaction logs for failures or skipped packages
sudo journalctl -xeu dnf
The -x flag adds explanatory text to journal entries, and -e jumps to the end of the log. Most sysadmins type journalctl -xeu <unit> as muscle memory. Read the actual error before guessing.
Build dependencies and the RPM ecosystem
Compiling a single C file only requires gcc and make. Compiling a full project usually requires header files, shared libraries, and development symbols. Fedora splits runtime libraries from development headers into separate -devel packages. This keeps production systems small and prevents accidental header pollution.
When you want to rebuild an existing Fedora package from its source RPM, you do not hunt for headers manually. DNF can resolve the exact build environment for you.
# Install every dependency required to build a specific package
sudo dnf builddep <package-name>
# --downloadonly fetches the source RPM without installing it
# This lets you inspect the spec file before committing disk space
dnf download --source <package-name>
The builddep command reads the package's .spec file and installs every BuildRequires entry. It also respects your current architecture and enabled repositories. If you skip this step, rpmbuild will fail with missing header errors that take hours to trace.
# Set up the standard RPM build tree in your home directory
rpmdev-setuptree
# Rebuild the source RPM into binary packages for your architecture
rpmbuild --rebuild <package-name>-*.src.rpm
The rpmdev-setuptree command creates ~/rpmbuild/{BUILD,BUILDROOT,RPMS,SOURCES,SPECS,SRPMS}. This directory structure is the Fedora convention for packaging work. Never run rpmbuild from your home directory root. The build tree isolates compiled artifacts and prevents permission conflicts.
Config files in /etc/ are user-modified. Files in /usr/lib/ ship with the package. Edit /etc/. Never edit /usr/lib/. The same rule applies to RPM macros and build configurations. Keep your customizations in ~/.rpmmacros or /etc/rpm/macros.
Trust the package manager. Manual file edits drift, snapshots stay.
Common pitfalls and what the errors look like
Developers hit three predictable walls when setting up Fedora build environments. Each one has a specific error signature and a direct fix.
Missing header files
The compiler stops with fatal error: openssl/ssl.h: No such file or directory. The runtime library is installed, but the development headers are not. Install the matching -devel package.
# Install the development headers for a specific library
sudo dnf install openssl-devel
# --setopt=install_weak_deps=False prevents pulling in optional test suites
# This keeps the build environment focused on compilation targets
SELinux denials for custom binaries
You compile a tool and run it, but the shell prints Permission denied even though ls -l shows rwxr-xr-x. SELinux blocks execution because the file carries an incorrect context. Check the audit log.
# Search recent AVC denials to see what SELinux blocked
sudo ausearch -m AVC -ts recent
# Restore the default context for files in your current directory
sudo restorecon -v .
SELinux denials show up in journalctl -t setroubleshoot with a one-line summary. Read those before disabling SELinux. The restorecon command fixes 90 percent of context mismatches by applying the policy defaults to your files.
Firewall blocking local development servers
Your Node.js or Python dev server starts, but your browser cannot reach localhost:8080. The runtime firewall rules do not match your persistent configuration, or the port is closed entirely.
# Open port 8080 for TCP traffic in the persistent firewall configuration
sudo firewall-cmd --permanent --add-port=8080/tcp
# Reload the firewall to apply the persistent rule to the running system
sudo firewall-cmd --reload
Always run firewall-cmd --reload after every rule change. Otherwise the runtime config and the persistent config diverge, and your changes vanish on reboot. Verify the rule with sudo firewall-cmd --list-ports.
Run journalctl -xe first. Read the actual error before guessing.
When to use this vs alternatives
Use the Development Tools group when you need a complete C and C++ compilation environment with debuggers and autotools. Use dnf builddep when you are rebuilding an existing Fedora package from its source RPM. Use language-specific managers like rustup or pyenv when you need multiple isolated versions of a runtime that DNF does not track. Use the C Development Tools and Libraries group when your project requires GUI toolkits, database clients, or network libraries. Stick to the base Development Tools group if you only compile standard CLI utilities and want a minimal footprint.
Pick the toolchain that matches your dependency graph. Do not install the full library group for a simple C script.