Why gcc fails when building CUDA extensions, and how to fix it
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
- 1Check nvcc --version and look up your CUDA toolkit's documented supported host compiler range.
- 2Install an older, supported gcc and g++ version alongside your system default, e.g. sudo apt install gcc-11 g++-11.
- 3Point the build at the older compiler explicitly: export CC=gcc-11 CXX=g++-11.
- 4Retry the failing pip install or build command in the same shell session.
- 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
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.
sudo apt install gcc-11 g++-11 export CC=gcc-11 CXX=g++-11 pip install flash-attn --no-build-isolation
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.
update-alternatives --list gcc sudo update-alternatives --config gcc
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.
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.
sudo apt install g++
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.
Size it properly next time
Free calculators that prevent this class of failure before you provision hardware.
Self-Hosted LLM Hardware Estimator
Estimate the VRAM footprint, GPU count, and hardware budget required to self-host an open-weight LLM with your concurrency and context needs.
Free ToolGPU Sizing Calculator for LLM Inference
Work out how many GPUs you need to serve a given open-weight model to your user base, based on memory footprint and token throughput.
Free ToolOn-Prem AI Deployment Checklist
A 30-point pre-deployment checklist covering use cases, hardware, security, model operations, and rollout for self-hosted enterprise LLMs.
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.
GuideKV 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.
GuidevLLM 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.