CMake tool discovery fails with custom compiler

Usage
1

Hi,

I’m trying to build my project with the scorep compiler wrapper for
Instrumentation.

However when calling cmake and setting the compiler via command line (as is described in their docu) the build fails.
(http://scorepci.pages.jsc.fz-juelich.de/scorep-pipelines/doc.r14395/scorepwrapper.html)

$ SCOREP_WRAPPER=off cmake .. \
    -DCMAKE_C_COMPILER=scorep-gcc \
    -DCMAKE_CXX_COMPILER=scorep-g++

[ 11%] Linking C static library libDHT.a
cd /home/maxschro/kivibench/build-scorep/lib/DHT && /usr/local/apps/cmake/3.18.0/bin/cmake -P CMakeFiles/DHT.dir/cmake_clean_target.cmake
cd /home/maxschro/kivibench/build-scorep/lib/DHT && /usr/local/apps/cmake/3.18.0/bin/cmake -E cmake_link_script CMakeFiles/DHT.dir/link.txt --verbose=1
CMAKE_AR-NOTFOUND qc libDHT.a CMakeFiles/DHT.dir/DHT.c.o
Error running link command: No such file or directory

After enabling verbose logging I noticed that the compiler was found,
but none of the gcc and system toolchain.

CMAKE_ADDR2LINE:FILEPATH=CMAKE_ADDR2LINE-NOTFOUND
CMAKE_AR:FILEPATH=CMAKE_AR-NOTFOUND
CMAKE_C_COMPILER_AR:FILEPATH=CMAKE_C_COMPILER_AR-NOTFOUND
CMAKE_C_COMPILER_RANLIB:FILEPATH=CMAKE_C_COMPILER_RANLIB-NOTFOUND
CMAKE_LINKER:FILEPATH=CMAKE_LINKER-NOTFOUND
CMAKE_OBJCOPY:FILEPATH=CMAKE_OBJCOPY-NOTFOUND
CMAKE_STRIP:FILEPATH=CMAKE_STRIP-NOTFOUND

I also tried to set the compiler via environment variable with the same
result.

When trying to change the Compiler with set in the CMakeLists.txt before
the project command the compiler didn’t change at all.

cmake_minimum_required(VERSION 3.11)
set (CMAKE_C_COMPILER=/usr/local/apps/scorep/4.0/bin/scorep-gcc)
# set the project name
project(Kivibench C)

If I set the need toolchain via command line everything works.
SCOREP_WRAPPER=off cmake … -DCMAKE_C_COMPILER=scorep-gcc -DCMAKE_CXX_COMPILER=scorep-g++ -DCMAKE_C_COMPILER_AR=/usr/bin/gcc-ar-6 -DCMAKE_AR=/usr/bin/ar -DCMAKE_LINKER=/usr/bin/ld

I’m using cmake version 3.18.0-rc3.

Is this the expected behavior? How can i set a custom compiler without
needing to set the ar? And if I need to set it is there a way to set in
the CMakeLists.txt?

Thank you,
Max

PS: I have also attached the CMakeOutput.log files for the run with set
and the command line options.

CMakeOutput-set.log (17.6 KB)

CMakeOutput-cmd.log (17.5 KB)

2

What I found worked reliably for me is to set CC and CXX (and, as needed, CUDACXX) environment variables before running cmake.

Remember that the compiler is saved in the cache, so I’d start with a new build directory whenever you change. And, to make your life easier, I’d make a script that captures all your required customizations before running cmake.

3

Hi

thanks for the advice, however I’ve already tried setting the compiler via environment variable and got the same result as setting it via cmake option (-DCMAKE_C…).
I also threw my build directory away between each test.
I’m also using a script right now for the builds because I have to set the whole toolchain via command line options. :slight_smile: But isn’t there a way to get cmake’s toolchain detection working with a custom compiler?

4

IIRC this behavior is intended to find the proper tools for GCC with a prefix. So it finds that the gcc executable has a prefix “scorep-” and uses that to find all other related tools.

5

Hi Hendrik,

thanks and I think you are right, because if I don’t use their gcc wrapper but instead the following everything works fine.

cmake --verbose … -DCMAKE_C_COMPILER=scorep -DCMAKE_C_COMPILER_ARG1=gcc

Since I didn’t find any Documentation about “CMAKE_C_COMPILER_ARG1” is this variable deprecated or should it not be used?

6

YMMV, and if this doesn’t work in your environment, I believe you, but I want to emphasize the difference between setting CC and CXX versus setting CMAKE_C_COMPILER and CMAKE_CXX_COMPILER. What I’m suggesting may very well be an anti-pattern; I’m just reporting that it works for me.

7

I dont think it is a antipatern, espacially since its recommended in the FAQs. However your persisitence made me also try to set CC to the scorep tool including parameters (not the wrapper) and CMake actually parsed that correctly. Thanks now I don’t have to override the internal ARG1 variable.

8

You should consider using the C_COMPILER_LAUNCHER property, which is initialized by the value of the CMAKE_C_COMPILER_LAUNCHER variable.

9

Dear Hendrik,

do you have any pointers since when this intended behavior exists, where it is documented, and (as it is good habit for heuristics), how to disable it?

Thanks.

10

I don’t think there are mechanisms to disable it. It’s probably just considered part of “how to find a GCC toolchain” since cross-compilers tend to use prefixes for the entire toolchain. Please open an issue requesting documentation of this behavior; it can’t hurt to have it mentioned somewhere.