Installation & Environmentcudapytorch

Why gcc fails when building CUDA extensions, and how to fix it

Error
error: unsupported GNU version! gcc versions later than 12 are not supported

Also appears as

  • nvcc fatal : Unsupported gcc versions
  • error: command 'gcc' failed with exit status 1

Short answer

Every CUDA toolkit release only supports compiling with a specific range of gcc and g++ major versions, and nvcc explicitly rejects anything outside that range rather than risk generating broken code. This most often surfaces on recently released Linux distributions whose default gcc is newer than what an older, already-installed CUDA toolkit supports, and the fix is installing a supported older gcc/g++ version alongside the default and pointing CC and CXX at it for the build.

Affects: Building any CUDA extension from source, including FlashAttention, bitsandbytes, or custom kernels, on newer Linux distributions with a default gcc/g++ ahead of what the installed CUDA toolkit supports.

Fastest path to a successful build

  1. 1Check nvcc --version and look up your CUDA toolkit's documented supported host compiler range.
  2. 2Install an older, supported gcc and g++ version alongside your system default, e.g. sudo apt install gcc-11 g++-11.
  3. 3Point the build at the older compiler explicitly: export CC=gcc-11 CXX=g++-11.
  4. 4Retry the failing pip install or build command in the same shell session.
  5. 5Unset CC and CXX afterward if other builds on the same machine need the newer default compiler.

How to confirm this is your problem

  • nvcc explicitly reports an unsupported GNU version with a specific gcc version number
  • Build fails immediately at the compiler check stage, before any real CUDA kernel code compiles
  • The same source builds fine on an older Linux distribution but fails on a freshly installed newer one
  • Error mentions gcc failing with exit status 1 with little further detail in the log

Root causes and fixes

Most common

System default gcc/g++ is newer than the CUDA toolkit's supported compiler range

Each CUDA toolkit release documents a specific supported range of host compiler versions, since nvcc needs to invoke gcc or g++ to process the non-CUDA C++ portions of source files. Recently released Linux distributions ship increasingly new gcc versions by default, and once that default gcc exceeds the upper bound a given CUDA toolkit was validated against, nvcc refuses to proceed rather than risk silently miscompiling code.

Fix: Install an older gcc/g++ version known to be supported by your CUDA toolkit release, and set CC and CXX environment variables to point at it explicitly for the duration of the build.

Commands
sudo apt install gcc-11 g++-11
export CC=gcc-11 CXX=g++-11
pip install flash-attn --no-build-isolation
Common

Multiple gcc versions installed but the wrong one is selected

Machines that have accumulated several gcc versions over time through different package installs may have update-alternatives configured to point at a newer version by default, or leftover CC/CXX environment variables from an earlier session pointing at the wrong compiler, causing the same unsupported version error even though a working older gcc is already present on disk.

Fix: List installed gcc versions and use update-alternatives or explicit CC/CXX environment variables to select the one your CUDA toolkit supports, rather than assuming only one gcc exists on the machine.

Commands
update-alternatives --list gcc
sudo update-alternatives --config gcc
Common

Building inside a container whose base image gcc does not match the CUDA version

A Dockerfile that installs a specific CUDA toolkit version but relies on the base image's default system packages for gcc can end up with the same mismatch seen on bare metal, since container base images track their own distribution's gcc release cadence independently of which CUDA toolkit version you chose to install inside them.

Fix: Explicitly install and select a compatible gcc/g++ version inside the Dockerfile rather than relying on whatever the base image ships by default, and pin this as part of your reproducible build image.

Occasional

g++ is missing even though gcc is installed

nvcc needs a C++ host compiler specifically, not just a C compiler, to process CUDA extension code that typically includes C++ features. Some minimal installations or base images include gcc for basic C compilation but omit g++ entirely, causing the build to fail looking for a C++ compiler that was never installed rather than a version mismatch.

Fix: Install the g++ package explicitly alongside gcc, since many distributions package them separately even though they are usually installed together.

Commands
sudo apt install g++
Rare

CUDA toolkit itself predates support for the distribution's default gcc entirely

On very new Linux distributions paired with an intentionally older, pinned CUDA toolkit version (for reasons of driver compatibility elsewhere in the stack), there may be no supported gcc version combination at all, since the toolkit release predates the existence of any compiler version the distribution ships or makes easily installable.

Fix: Upgrade the CUDA toolkit itself to a release that documents support for a gcc version available on your distribution, since downgrading gcc alone will not resolve toolkit releases old enough to have no compatible compiler option.

Diagnostic commands

Check the exact CUDA toolkit version in use

nvcc --version

Look up this specific version's documented supported gcc/g++ range in NVIDIA's CUDA toolkit release notes before choosing a compiler version to install.

Check the system default compiler version being rejected

gcc --version

Compare this major version number directly against the range nvcc's error message and the toolkit documentation state as supported.

Confirm g++ is installed at all, not just gcc

g++ --version

A command-not-found error here means the missing C++ compiler, not a version mismatch, is the actual problem, and installing g++ resolves it directly.

Confirm which compiler the build will actually invoke

echo $CC $CXX

If these environment variables are unset, the build uses the system default; if set to an unexpected value from a previous session, that stale value may be the real cause of the failure.

Stopping it from happening again

  • Pin a known-compatible gcc/g++ version explicitly in your build scripts and Dockerfiles rather than relying on the distribution's default.
  • Check the CUDA toolkit's documented supported compiler range before upgrading either the OS or the toolkit independently.
  • Bake a validated build environment with the correct compiler version into a reusable container image for compiling CUDA extensions.
  • Document which gcc version each CUDA toolkit release in your fleet requires, so future engineers do not rediscover this from scratch.

When this becomes an architecture problem

If you regularly need to build CUDA extensions from source across a fleet with mixed CUDA toolkit versions and OS releases, invest in a small set of standardized build container images that pin the correct compiler per CUDA version, rather than resolving this compiler mismatch by hand on every new machine or OS upgrade.

Frequently asked questions

Why does nvcc reject a perfectly working, up-to-date gcc?

nvcc validates the host compiler version against a specific supported range documented for each CUDA toolkit release, because generating correct code depends on known compiler behavior that NVIDIA has tested against. A newer gcc than that range, even if it works fine for every other purpose on your system, falls outside what that CUDA toolkit version has been validated to work with.

Can I just remove the newer gcc and only keep the older one?

You can, but installing the older gcc/g++ alongside the existing default and using CC/CXX environment variables or update-alternatives to select it for CUDA builds is usually safer, since other tools and system packages on the same machine may depend on the newer default gcc for unrelated builds.

Does this compiler restriction only affect FlashAttention and bitsandbytes?

No, it affects any CUDA extension compiled from source using nvcc, including custom kernels, DeepSpeed's fused kernels, and other libraries that compile CUDA code at install time. Prebuilt wheels sidestep this entirely, which is why using a matching prebuilt wheel is usually preferable to a from-source build whenever one is available.

How do I find out which gcc versions my CUDA toolkit supports?

Check NVIDIA's official CUDA toolkit release notes or installation guide for the specific version reported by nvcc --version; they document the exact supported host compiler range for that release. This is more reliable than guessing based on the error message alone, since the message names the version being rejected, not necessarily the full supported range.

Related problems

FlashAttention install fails during compilation or gets killed

FlashAttention's pip install compiles CUDA kernels from source unless an exact prebuilt wheel exists for your torch, CUDA, Python, and C++ ABI combination, and that compilation is extremely RAM-hungry per parallel job. The build gets silently OOM-killed on machines without enough memory unless you limit MAX_JOBS, and separately fails if your CUDA toolkit does not match the version torch itself was built against.

vLLM fails to install or import due to torch and CUDA mismatches

vLLM ships prebuilt wheels compiled against a specific, exact torch and CUDA version, and it uses custom CUDA kernels that only work with that pairing. Most install failures happen because torch was already installed separately, or an existing environment has an incompatible CUDA toolkit, so the fix is almost always a fresh virtual environment where pip resolves vLLM and its exact torch dependency together in one pass.

bitsandbytes cannot find or detect a working CUDA setup

bitsandbytes needs to locate the exact CUDA runtime shared library at import time and load a matching precompiled binary for that version. The setup fails most often because LD_LIBRARY_PATH points at a different CUDA installation than the one it detected, or because an older bitsandbytes version could not auto-detect the GPU correctly. Upgrading to the latest bitsandbytes and running its built-in diagnostic resolves the majority of cases.

Python dependency conflicts across transformers, tokenizers, and numpy

The Hugging Face stack (transformers, tokenizers, accelerate) is released in tightly coupled lockstep versions, so upgrading one package independently over time leaves combinations that were never tested together and break silently at import or runtime. The fix is resolving the entire stack in a single pip install pass from a fresh virtual environment, guided by a pinned requirements.txt, rather than incrementally patching individual packages.

Guide

KV Cache Optimization: Prefix Caching and Chunked Prefill

KV cache optimization techniques for production LLM serving: prefix caching, chunked prefill, PagedAttention, and sizing memory for concurrent users.

Guide

vLLM Production Deployment: A Practitioner's Guide

Deploy vLLM in production: continuous batching, PagedAttention, config flags that matter, and the metrics to watch before you trust it with real traffic.

Still stuck, or tired of fighting your own infrastructure?

Netray deploys and operates on-prem AI for regulated manufacturers and defense suppliers. We have debugged this stack in production, on air-gapped networks, at scale.