Detect the host compiler instead of hardcoding gcc-15 - #2
Merged
Conversation
cuda-env.sh hardcoded CC=/usr/bin/gcc-15, and check-env printed that path without ever testing it. On a host that never installed gcc 15 — the CUDA runfile installed directly rather than through install-cuda-toolkit.sh, which does check — the gate passed, and the build died in cmake twelve minutes later, after a 1.4 GB clone and a full submodule sync: The CMAKE_CXX_COMPILER: /usr/bin/g++-15 is not a full path to an existing compiler tool. The compiler is now probed: gcc-15, gcc-14, gcc-13, then plain gcc. Versioned binaries come first deliberately. nvcc refuses a host compiler newer than the cap in its own crt/host_config.h, CUDA 13.3 stops at gcc 15, and a rolling distro's default runs ahead of that — Manjaro is on 16 — so the unversioned binary is the fallback, not the preference. check-env now earns its "fails fast on anything missing" claim for the compiler too: CC and CXX must be executable, and the resolved gcc major must not exceed the cap parsed out of the toolkit's own host_config.h. Both failures name the package to install. Verified on this machine: detection resolves gcc-15 with gcc 16 as the system default, a missing compiler and an over-cap compiler each fail check-env with an actionable message, and the probe falls back to the unversioned binary only when no versioned one exists.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Follow-on to #1, found by running the first build through to its next failure.
make check-envpassed, then twelve minutes of clone and submodule sync later cmake said:cuda-env.shhardcodedCC=/usr/bin/gcc-15, andcheck-envprinted that path without ever testing it. On a host that never installed gcc 15 — CUDA runfile run directly, rather than throughinstall-cuda-toolkit.sh, which does check — the gate passed on a machine that could not compile.Changes
cuda-env.shprobes for the host compiler:gcc-15,gcc-14,gcc-13, then plaingcc. Versioned first is deliberate — nvcc refuses a host compiler newer than the cap in its owncrt/host_config.h, CUDA 13.3 stops at gcc 15, and a rolling distro's default runs ahead of that (Manjaro is on 16). The unversioned binary is the fallback, not the preference.CC/CXXstill win if already exported.check-envvalidates the result:CCandCXXmust be executable, and the resolved gcc major must not exceed the cap parsed out of$CUDA_HOME/include/crt/host_config.h. Both failures name the package to install.check-envenforces.Verification
On a box with gcc 16 as the system default and
gcc15installed alongside: detection resolves/usr/bin/gcc-15; a nonexistentCCfailscheck-envwith the install hint;CC=/usr/bin/gcc(16) fails withis gcc 16, and this CUDA supports up to gcc 15; and the probe falls back to the unversioned binary only when no versioned one exists.make checkpasses with the CI-pinned shellcheck 0.11.0.