Hi, i have both gcc 12 and gcc 13 installed (gcc 13 is default).
when i tried to emerge sci-libs/cholmod-3.0.14 with USE=cuda, it fails with:
"/opt/cuda/bin/../targets/x86_64-linux/include/crt/host_config.h:132:2: error: #error -- unsupported GNU version! gcc versions later than 12 are not supported! The nvcc flag '-allow-unsupported-compiler' can be used to override this version check; however, using an unsupported host compiler may cause compilation failure or incorrect run time execution. Use at your own risk."
Using /etc/portage/package.env and set cholmod to use gcc-12 (according to this: viewtopic-t-1159911-highlight-.html) - doesn't help, though the same works with other packages.
But after switching to gcc 12 with gcc-config - sci-libs/cholmod builds without any issue.
So what can be missing here for this to work?
# cat /etc/portage/env/gcc-12.conf
CC=/usr/bin/gcc-12
CXX=/usr/bin/g++-12
gcc switch issue
Message
Hello there
I don't mean to sound patronising but
Build it with GCC 12, and then gcc-config back to 13.
I would do it this way and just avoid playing with package.env.
Would that not solve the problem?
I don't mean to sound patronising but
is saying build cholmod with GCC 12.unsupported GNU version! gcc versions later than 12 are not supported!
Exactly. Because the output says it should be built with GCC 12 and not 13.But after switching to gcc 12 with gcc-config - sci-libs/cholmod builds without any issue.
Build it with GCC 12, and then gcc-config back to 13.
I would do it this way and just avoid playing with package.env.
Would that not solve the problem?
Whatever you do, do it properly!
OP's stated problem is that package.env is expected to work here, and did not. Using gcc-config requires the user to intervene every time this package is built. A working solution based on package.env would allow the user to run emerge --emptytree @world or similar and get the right results. A workaround built on gcc-config does not, because it requires switching compilers between packages.
I cannot comment on why package.env did not work here, though I seem to recall recently reading a thread that suggested CC and CXX are not among the variables that package.env can change. OP: the cited forum thread has two steps for configuring package.env, but you only showed one. Did you do both? If yes, please show the relevant lines from the other file.
I cannot comment on why package.env did not work here, though I seem to recall recently reading a thread that suggested CC and CXX are not among the variables that package.env can change. OP: the cited forum thread has two steps for configuring package.env, but you only showed one. Did you do both? If yes, please show the relevant lines from the other file.
- leonchik1976
- Guru
- Posts: 344
- Joined: Sun Jan 24, 2010 1:28 pm
i believe my problem is somehow related to nvcc flags, because the issue is only with CUDA-related use-flag packagesHu wrote:OP's stated problem is that package.env is expected to work here, and did not. Using gcc-config requires the user to intervene every time this package is built. A working solution based on package.env would allow the user to run emerge --emptytree @world or similar and get the right results. A workaround built on gcc-config does not, because it requires switching compilers between packages.
I cannot comment on why package.env did not work here, though I seem to recall recently reading a thread that suggested CC and CXX are not among the variables that package.env can change. OP: the cited forum thread has two steps for configuring package.env, but you only showed one. Did you do both? If yes, please show the relevant lines from the other file.