Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

nvcc package should constrain c / cxx compiler versions based on cuda version #51

Open
kkraus14 opened this issue Nov 25, 2020 · 13 comments

Comments

@kkraus14
Copy link
Contributor

Compatibility matrix: https://gist.github.com/ax3l/9489132

Latest versions supported:

CUDA Version GCC Version
9.2 7
10.0 7
10.1 8
10.2 8
11.0 9
11.1 10
@jaimergp
Copy link
Member

I was thinking about this too. Is this to be addressed as part of the global pinnings at conda-forge-ci-pinning via zipped_keys?

@jakirkham
Copy link
Member

IIRC Keith we are only worried about this for packages that actually contain CUDA kernel code right? Not packages that merely link to CUDA libraries. Is that correct or am I missing something?

@kkraus14
Copy link
Contributor Author

Any code that compiled with nvcc, so even if they don't have device code if they use a .cu extension it will go through nvcc.

@leofang
Copy link
Member

leofang commented Nov 29, 2020

I think this should be fixed asap, as Conda-Forge has updated the global pinning to gcc9, and cupy-feedstock starts to see tons of build errors due to incompatible host compiler versions: conda-forge/cupy-feedstock#80 (comment).

@leofang
Copy link
Member

leofang commented Nov 29, 2020

Any code that compiled with nvcc, so even if they don't have device code if they use a .cu extension it will go through nvcc.

Even worse, any host code that is compiled by host compilers and includes cuda_runtime.h will also be affected (see the cupy error linked above).

@kkraus14
Copy link
Contributor Author

Looks like it's more than just libraries with device code based on the above.

@jakirkham
Copy link
Member

What happens if we build against GCC 7 and the runtime library from GCC 9 is pulled in by the compiled packages?

@kkraus14
Copy link
Contributor Author

kkraus14 commented Dec 7, 2020

What happens if we build against GCC 7 and the runtime library from GCC 9 is pulled in by the compiled packages?

As far as I'm aware that should be fine, there's just compiler checks in the headers that prevent using too new of a compiler.

@leofang
Copy link
Member

leofang commented Dec 29, 2020

Update: with conda-forge/conda-forge-pinning-feedstock#1052 all CUDA builds fall back to gcc 7 now, so it works for all CUDA versions (9.2 - 11.0). It'd be great to enable gcc 9 for CUDA 11.0+ only.

@jakirkham
Copy link
Member

Does PR ( conda-forge/conda-forge-pinning-feedstock#2010 ) sufficiently address this concern @kkraus14? Or are there other things still needed?

@kkraus14
Copy link
Contributor Author

Does PR ( conda-forge/conda-forge-pinning-feedstock#2010 ) sufficiently address this concern @kkraus14? Or are there other things still needed?

I believe it generally handles things for building packages within conda-forge, but if someone was to use the nvcc and gcc packages themselves they can still land themselves in an incompatible situation as far as I can tell.

@jakirkham
Copy link
Member

Suppose we could add run_constrained to the package

@robertmaynard
Copy link

The compatiblity matrix listed above and the one on the CUDA Linux installation guide ( https://docs.nvidia.com/cuda/cuda-installation-guide-linux/index.html ) list the maxium supported gcc version, not the minimum.

This is clarified in footnote 2 of the CUDA docs where CUDA 11.X requires at least gcc 6.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants