[bug] detect_default_compiler fails in ubuntu 22 docker when cc is '/usr/bin/cc'

[Stadik]

Describe the bug

It seems to be a tricky issue since it only occurs in a fresh docker image first time after install.
Only when calling 'conan profile detect' via cmake script.
The reason is probably how cmake sets CC to /usr/bin/cc since it does not happen when directly calling conan profile detect.

The issue seems to be (in 2.2.3) in conan/internal/api/detect_api.py , detect_default_compiler, line 363
command is set to /usr/bin/cc but in the gcc if condition cc is not tested

Adding or or "cc" in command to line 369 fixes the issue.

@@ -363,7 +363,7 @@
         command = cc or cxx
         if "clang" in command.lower():
             return _clang_compiler(command)
-        if "gnu-cc" in command or "gcc" in command or "g++" in command or "c++" in command or "cc" in command:
+        if "gnu-cc" in command or "gcc" in command or "g++" in command or "c++" in command:
             gcc, gcc_version, compiler_exe = _gcc_compiler(command)
             if platform.system() == "Darwin" and gcc is None:
                 output.error("%s detected as a frontend using apple-clang. "

How to reproduce it

when following these steps it always occurs for me (maybe not all is necessary, but I didn't test it without them)

sudo docker run -it nvidia/cuda:11.7.1-devel-ubuntu22.04 /bin/bash 
apt update
apt install lsb-release python3-pip 
pip3 install cmake conan

By running this CMakeLists.txt

cmake_minimum_required(VERSION 3.16)

project(Test VERSION 0.0.0)
enable_language(CUDA)

execute_process(
        COMMAND conan profile detect --name default
        WORKING_DIRECTORY ${CMAKE_BINARY_DIR}
        OUTPUT_VARIABLE CONAN_OUTPUT
        OUTPUT_STRIP_TRAILING_WHITESPACE
)

One gets this error

-- The C compiler identification is GNU 11.4.0
-- The CXX compiler identification is GNU 11.4.0
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /usr/bin/cc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/c++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- The CUDA compiler identification is NVIDIA 11.7.99
-- Detecting CUDA compiler ABI info
-- Detecting CUDA compiler ABI info - done
-- Check for working CUDA compiler: /usr/local/cuda/bin/nvcc - skipped
-- Detecting CUDA compile features
-- Detecting CUDA compile features - done
detect_api: CC and CXX: /usr/bin/cc, /usr/bin/c++ 
detect_api: ERROR: Not able to automatically detect '/usr/bin/cc' version
WARN: No compiler was detected (one may not be needed)

[memsharded]

Thanks for reporting this @Stadik, and thanks specially for the detailed and reproducible example, that really helps.

It indeed seems a bug, lets try to improve it.

I think this fix might not be that straightforward as proposed above, as usr/bin/cc can also be made to point to clang, with update-alternatives, isn't it? So it cannot be assumed that it will be gcc, as it can be clang, and it has to be checked.

[memsharded]

I have been having a closer look to this.

It seems that CMake has acknowledge this was not a great default behavior in https://gitlab.kitware.com/cmake/cmake/-/issues/21378, and it was changed in https://gitlab.kitware.com/cmake/cmake/-/merge_requests/7108, but for older cmake_minimum_required() it requires activating a policy.

I have modified your CMakeListst.txt to cmake_minimum_required(VERSION 3.24), and now everything works fine.

I was surprised that we hadn't suffered this issue in cmake-conan integration (https://github.com/conan-io/cmake-conan), which is basically doing that, calling conan profile detect, but as it is using CMake providers and it requires CMake>=3.24, we hadn't detected this.

I think we could considered this issue as not a Conan issue, but a CMake one, and it has already been solved, what do you think?

[Stadik]

Thanks for investigating this issue so fast.

Yes you are right this error can be fully controlled just by cmake_policy(SET CMP0132 NEW), so it certainly is a cmake issue in this case.

This is quite interesting, everything happens silently in the background, also by changing this policy there is no visible difference to identify the actual issue.

[Stadik]

I think this fix might not be that straightforward as proposed above, as usr/bin/cc can also be made to point to clang, with update-alternatives, isn't it? So it cannot be assumed that it will be gcc, as it can be clang, and it has to be checked.

Yes true just by symlinks "/usr/bin/cc" and "/usr/bin/c++" one cannot tell what the actual compiler is, but I can see the if condition is also checking "c++" in command.
So in case one sets clang as update-alternative, this could create the same problematic scenario, where it is actually pointing against clang++, but gcc is identified?

So it seems for me command containing this would create the need to resolve the symlink to identify if it is clang or gcc?

[memsharded]

So in case one sets clang as update-alternative, this could create the same problematic scenario, where it is actually pointing against clang++, but gcc is identified?

This code applies only when the CC/CXX env-var is defined.
If this variable is not defined, then it will be checking the cc executable and it will already read the output for clang/gcc to differentiate which one it is. (this is a fix for next Conan 2.3 in #16074)

What it doesn't seem to make sense is users pointing the CC/CXX env-var to the /usr/bin/cc location, I'd say it is not expected that users would be setting this.

[Stadik]

Thanks a lot, I can verify that 2.3.0 fixes the original issue I used to derive the example from.

[memsharded]

Thanks for the feedback @Stadik