On my system I have both gcc8 and gcc9 installed, with gcc8 being set as the default system compiler: eselect gcc list [1] x86_64-pc-linux-gnu-8.3.0 * [2] x86_64-pc-linux-gnu-9.3.0 In my user shell I want to use gcc9 to work on my own project, so I run this command: eval $(gcc-config --print-environ 2) which sets my PATH to /usr/x86_64-pc-linux-gnu/gcc-bin/9.3.0:/usr/lib/llvm/9/bin:/usr/lib/llvm/8/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/opt/bin and gcc --version correctly reports 9.3.0. However cmake still picks up gcc8. To reproduce: in an empty directory "test" create a CMakeLists.txt file with this content: cmake_minimum_required(VERSION 3.0 FATAL_ERROR) project(test C) add_executable(test main.c) then cd into test and: touch main.c cmake . this is the output I get: -- The C compiler identification is GNU 8.3.0 -- Check for working C compiler: /usr/bin/cc -- Check for working C compiler: /usr/bin/cc -- works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Detecting C compile features -- Detecting C compile features - done -- Configuring done -- Generating done The issue seems to be with cmake looking for the "cc" command, which is missing in the /usr/x86_64-pc-linux-gnu/gcc-bin/9.3.0 directory so the default /usr/bin/cc gets used. Adding a cc symlink to x86_64-pc-linux-gnu-gcc in that directory fixes the problem for me.
It is sad to read that you have problems with the software. The situation seems to be a bit more complicate and requires some analysis. We can not help you efficiently via bug tracker. The bug tracker aims rather on specific problems in .ebuilds and less on individual systems. I have had very good experience on the gentoo IRC [1] with questions like this. Of course there are also forums and mailing lists [2,3]. I hope you understand, that I will close the bug here therefore and wish you good luck on one of the mentioned channels [4]. Please reopen the ticket in order to provide an indication for an specific error in an ebuild or any gentoo related product. [1] https://www.gentoo.org/get-involved/irc-channels/ [2] https://forums.gentoo.org/ [3] https://www.gentoo.org/get-involved/mailing-lists/all-lists.html [4] https://www.gentoo.org/support/
> The situation seems to be a bit more complicate and requires some analysis. Hi, to be honest, unless I'm missing something, this issue is not very complicated, it's just a missing symlink. What is the part that requires some analysis and is causing you concern? > We can not help you efficiently via bug tracker. This confuses me. What are you interpreting this situation like? I'm trying to contribute to gentoo by reporting an issue and providing what *I think* the fix would be. You could say I'm trying to help you, or rather we're helping each other. This is a libre/open source community. > Please reopen the ticket in order to provide an indication for an specific error in an ebuild or any gentoo related product. Isn't gcc's ebuild a gentoo related product? Or are you suggesting I report this to upstream gcc? > I have had very good experience on the gentoo IRC [1] with questions like this. The #gentoo irc channel is usually my go-to place whenever I have a problem, but in my experience people there are not able or willing to change Gentoo packages on the fly. To be clear I'm not asking a question, I'm reporting an issue I encountered in gentoo. If any of what I said is not clear or doesn't make sense please feel free to quote the specific part and ask, I will try to provide as much detail as I can.
(In reply to King_DuckZ from comment #0) > On my system I have both gcc8 and gcc9 installed, with gcc8 being set as the > default system compiler: > > eselect gcc list > [1] x86_64-pc-linux-gnu-8.3.0 * > [2] x86_64-pc-linux-gnu-9.3.0 > > In my user shell I want to use gcc9 to work on my own project, so I run this > command: > > eval $(gcc-config --print-environ 2) > > which sets my PATH to > /usr/x86_64-pc-linux-gnu/gcc-bin/9.3.0:/usr/lib/llvm/9/bin:/usr/lib/llvm/8/ > bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/opt/bin > > and gcc --version correctly reports 9.3.0. However cmake still picks up > gcc8. To reproduce: > > in an empty directory "test" create a CMakeLists.txt file with this content: > > cmake_minimum_required(VERSION 3.0 FATAL_ERROR) > project(test C) > add_executable(test main.c) > > then cd into test and: > > touch main.c > cmake . > > this is the output I get: > > -- The C compiler identification is GNU 8.3.0 > -- Check for working C compiler: /usr/bin/cc > -- Check for working C compiler: /usr/bin/cc -- works > -- Detecting C compiler ABI info > -- Detecting C compiler ABI info - done > -- Detecting C compile features > -- Detecting C compile features - done > -- Configuring done > -- Generating done > > The issue seems to be with cmake looking for the "cc" command, which is > missing in the /usr/x86_64-pc-linux-gnu/gcc-bin/9.3.0 directory so the > default /usr/bin/cc gets used. Adding a cc symlink to > x86_64-pc-linux-gnu-gcc in that directory fixes the problem for me. Your going about this wrong. You are depending on cc being called which will use the system compiler, if your really wanting to have gcc-9 used call x86_64-pc-linux-gnu-9.3.0-cc via CC=
CC=x86_64-pc-linux-gnu-gcc-9.3.0 cmake . will give you the results you are looking for if I was not clear earlier
Sun Mar 29 09:01 anarchy@bull test $ CC=aarch64-gentoo-linux-musl-gcc CXX=aarch64-gentoo-linux-musl-c++ cmake . -- The C compiler identification is GNU 9.3.0 -- Check for working C compiler: /usr/bin/aarch64-gentoo-linux-musl-gcc -- Check for working C compiler: /usr/bin/aarch64-gentoo-linux-musl-gcc - works -- Detecting C compiler ABI info -- Detecting C compiler ABI info - done -- Detecting C compile features -- Detecting C compile features - done -- Configuring done -- Generating done -- Build files have been written to: /home/anarchy/test Sun Mar 29 09:02 anarchy@bull test $ uname -a Linux bull 5.5.13-zen1-musl #1 ZEN SMP Sun Mar 29 08:04:22 CDT 2020 x86_64 Intel(R) Core(TM) i5-3320M CPU @ 2.60GHz GenuineIntel GNU/Linux This is the output of your example, which would work for cross compiling.
Hi Jory, that is what I used to do before discovering the gcc-config --print-environ command. If its output is not reliable then what's the purpose of that command?
(In reply to King_DuckZ from comment #6) > Hi Jory, that is what I used to do before discovering the gcc-config > --print-environ command. If its output is not reliable then what's the > purpose of that command? The problem is cc is a symlink in /usr/bin to system compiler, you have to override it. gcc-config shouldn't be used for anything more then setting the system compiler to whatever toolchain your wanting for the system.
(In reply to Jory A. Pratt from comment #7) > (In reply to King_DuckZ from comment #6) > > Hi Jory, that is what I used to do before discovering the gcc-config > > --print-environ command. If its output is not reliable then what's the > > purpose of that command? > > The problem is cc is a symlink in /usr/bin to system compiler, you have to > override it. gcc-config shouldn't be used for anything more then setting the > system compiler to whatever toolchain your wanting for the system. That's what I'm saying, if a symlink to cc was provided, as it's already the case for c++, cpp, gfortran etc, then everything would work. In fact it does work if I create that link myself manually. What's the advantage of *not* having a cc link in /usr/x86_64-pc-linux-gnu/gcc-bin/9.3.0? It might be I'm unknowingly abusing the purpose of gcc-config, but to me it's a very convenient way for switching between compilers only in a given shell, without requiring root privileges and without affecting the system beyond the current user. I think there are many advantages over the approach you suggested of manually specifying paths with CC and CXX (and... CD? whatever would be the variable for the D compiler, I don't even know).
closing here, because the bug tracker is not the right place for discussion. Please discuss/clarify on the provided channels. If it confirms that there is a bug, please open a new ticket and add the package in the summary.
I think /usr/bin/cc used to redirect almost correctly before https://gitweb.gentoo.org/proj/gcc-config.git/commit/?id=9b907ef80bc421df23515afc4c306e4d96c67649
bug #724980 should allow populating usful links to user environment without relying on default binaries that gcc provides.
