Disable compiler checks

Hello,

When running cmake it will try to find a suitable compiler and try to see if it can program a simple program with it.

  1. Can someone verify that if you specify a variable from the command line that this will not be passed to this test compilation and it will trash it?
  2. How can I disable these checks?

Can someone help please?

Thanks

1 Like

What kind of variable? Environment? Command line argument? To CMake itself? Do you have an example?

If you want CMake to compile C or C++ code, CMake needs to figure out what compiler it’s working with so that it can create the correct command lines to build your code. If you want to use a different compiler, you can set CC or CXX environment variables. There are also toolchain files you can use to specify more details for cross compilation.

Command line argument.

Basically I’m running this github repo GitHub - ObKo/stm32-cmake: CMake for stm32 developing. and you can see what I am trying to do here
Toolchain doesn't include correct gcc_stm32fx.cmake file · Issue #109 · ObKo/stm32-cmake · GitHub.
From the issue above I deduce that the command line argument is not being passed when doing the test compile.
And by running the cmake command with --trace I notice that toolchain file is included twice which is imo counter intuitive, even though I read somewhere that you should keep the toolchain fairly simple because it may be included multiple times.

I understand how to use a different compiler, but there are a few cases where you might want to pass an argument to the compiler even when doing a test build. From my limited experience it looks like this is impossible. When you specify a different compiler, let’s say arm-none-eabi-gcc, when testing the compiler it will run something simple such as arm-none-eabi-gcc test.c and it will definitely not include any command line arguments that may be needed.

Oh, that’s probably true. @brad.king Is there some way to pass additional CMAKE_FLAGS to the compiler detection try_compile internals? Or should these things be set directly in the toolchain file (as my gut is telling me is the sanctioned way)?

As I said above, I feel like this is supposed to be part of the toolchain file, but I am not super-well versed in them. Maybe it could do this via an include(OPTIONAL) to get the settings from a file somewhere?

Compiler flags that are always needed should either be in CMAKE_{C,CXX}_FLAGS (perhaps via CFLAGS and CXXFLAGS environment variables) or be added by code in a CMAKE_TOOLCHAIN_FILE. The toolchain file is always included in try_compile projects and so can add such flags consistently.

I think you have not addressed the Generate mode for CMake. I want to generate a Unix Makefile for Eclipse, to run on another machine. I only want to generate the new makefile, not test any compiler that exists on the machine used to generate the makefile. Therefore, there must be a way to disable these “compiler tests” because that has nothing to do with the target compiler. Eclipse uses Unix makefiles, not CMakeLists.txt files, thus the Generate function should be able to convert the bulk of CMakeLists.txt tree into a traditional makefile tree. If it cannot do this, then the concept of supporting cross-compilers is flawed. So the question really becomes “what command line option (like -Dxxxxx) will disable the Generator’s attempt to test some compiler?” Does anybody know the answer? Thanks, Grant.

This is not supported. Build trees have absolute paths baked into them and are not transferable between (non-identical) machines.

The way to fix this is to have CMake use your target compiler via a toolchain file. This toolchain must run on the host you configure CMake on. See these docs for making a toolchain file for your compiler set.

Cross compiling is supported in CMake and used all the time. It may not support the specific method of using them in the way you describe here, but they are supported.

Hi Ben:

Thank you for your reply.

I am starting with a CMakeFiles.txt file at the top of a tree chain. It works fine in VS2017 on Windows Intel machine, now I need to port it into Eclipse on target ARM machine.

My goal is to use this GENERATOR for Unix Makefiles for Eclipse target:

**cmake** <dest> **-G “Eclipse CDT4 - Unix Makefiles”** -DCMAKE_PROGRAM=make.exe -DCMAKE_C_COMPILER=NONE

but I don’t think NONE is an acceptable value (make.exe path is resolved by PATH environment).

I am looking for a way to disable the gcc.exe sample test feature because that test is failing.

Is there a -DCMAKE_COMPILER_TEST=0 option or something similar?

After I build the makefile chain for Unix, then I can import it into Eclipse and edit as necessary.

Thanks for your help.

Grant

Only by disabling C language support in your build. CMake needs to inspect the compiler so that it knows, e.g., how to generate the proper command lines for the compilation steps. It can’t be skipped if you want CMake to generate a build system.

Why is the test failing?

Hi Ben:

Thank you for your reply. it looks like I will have to leave gcc in place, but perhaps I need to install a GCC that is different from the “arm-none-eabi-gcc.exe” in some deep path.

It is failing with the output message indicating that something is “broken” and it cannot find _exit().

Here is the link to download the results, so perhaps you can find something in there.

Eclipse  => [https://files.secureserver.net/0fP9JIqPZAEGWX](https://files.secureserver.net/0fP9JIqPZAEGWX)

Thanks again for your help,

Grant.

Hmm. It seems like something is wrong with the compiler itself. Are you able to use it to compile a simple program from the command line outside of CMake? If that works, whatever environment you have in there, CMake will need to be run in that as well (any loaded environment modules, PATH settings, etc.) in order to use the compiler. If it doesn’t work outside, CMake isn’t going to be able to do much to work around that.

Hi Ben:

Thanks for the quick response.

The compiler works fine when launced from the Eclipse-Wiced IDE. I can also run “gcc —version" from anywhere (since the PATH environment variable includes the required bin folder), and I get the correct result. The first few lines in the Command Prompt screen capture show that both gcc and g++ returned a version number.

I could try running Cmake -G inside the project path for the main project. At the moment, I have two working areas: 1) a test area for CMake generation where I am trying to get an Eclipse makefile generated, and 2) the working area where Eclipse-Wiced IDE builds the makefile projects. Once I have a working makefile, then I will use in the Eclipse-Wiced working area.

How about I install a fresh copy of GCC in the test area. That is something that I think I should try.

Thanks again for your help.

Grant

Hi Ben:

I installed a fresh copy of GCC in C:\MinGW folder, and tested it worked with the new PATH variable.

The GCC does not work with my GEN9.BAT file, using CMake Generator.

Here is a link to download the files for this test:

Cake_Errors_2 => https://files.secureserver.net/0fFQcKGEcV8Jz1

I am still getting the same error, so something else is wrong.

Thanks for your help,

Grant.

———————— previously ——————

Hi Ben:

Thanks for the quick response.

The compiler works fine when launced from the Eclipse-Wiced IDE. I can also run “gcc —version" from anywhere (since the PATH environment variable includes the required bin folder), and I get the correct result. The first few lines in the Command Prompt screen capture show that both gcc and g++ returned a version number.

I could try running Cmake -G inside the project path for the main project. At the moment, I have two working areas: 1) a test area for CMake generation where I am trying to get an Eclipse makefile generated, and 2) the working area where Eclipse-Wiced IDE builds the makefile projects. Once I have a working makefile, then I will use in the Eclipse-Wiced working area.

How about I install a fresh copy of GCC in the test area. That is something that I think I should try.

Thanks again for your help.

Grant

If you can’t use the compiler from the same place you’re launching CMake, that is the first problem to be addressed.

But do you want to use the gcc that answers that --version request? Even so, something else can be broken that means it doesn’t produce viable compilations. Can you compile a simple source file with the compiler you want CMake to use on the command line where you are running CMake?

As for your latest upload, it seems that CMakeError.log is truncated.

Also, if you’re doing cross compilation (the resulting binaries cannot be run on the host machine), you should pass -DCMAKE_CROSSCOMPILING=1 to let it know that.

Hi Ben:

I have made some more tests, but I cannot solve this problem. Still have the gcc error with my simple main.c program. Maybe something is wrong in Environment Variables - don’t know.

I have zipped all the latest files for you to download from here:

TestCode.zip (1.2 MB) => [https://files.secureserver.net/0sc7BXRQnDTJIf](https://files.secureserver.net/0sc7BXRQnDTJIf)

If you have any more ideas how to fix the gcc.exe broken error, please let me know.

Thanks

Grant

TestCode.zip (1.21 MB)

See my reply in Generator for Eclipse CDT4 Unix Makefiles - Error - #5 by McMartin.
Please consider using a single thread for the same issue.

Except, if I want to compile C or C++ code CMake trying to link something with the command line switches I give to the frontend driver may be outright wrong.

Example: building the compiler and C runtimes. In order to bootstrap them, I should be able to work around the smart logic baked into CMake, should I not?

I found this Q&A when looking for something like that.

I recommend looking into how LLVM/Clang ends up doing this. However, note that CMake only supports a single toolchain per language in a single build, so using a compiler you just built using its own language is not supported in a single build tree. You can probably do some toolchain tricks to have CMake do what you want for a new compiler, but I don’t know how much is involved in that.

Thanks @ben.boeckel. And sorry for the delayed response.

Indeed it looks I may not be able to pull this off in single invocation of CMake. However, I found that there are a number of variables that I can use, but they are unfortunately a deprecated means of achieving what I want (according to the documentation).

This comment by @brad.king on the issue tracker referenced in this StackOverflow answer contains part of the answer and it’s not the answer I’d like :wink: … but mentions those variables (CMAKE_C_COMPILER_ID_RUN, CMAKE_C_COMPILER_FORCED and CMAKE_C_COMPILER_WORKS). I haven’t found a modern alternative, though. And since CMake doesn’t seem to make a distinction of “internal” and “external” variables (like the leading _ in vendor-specific C++ extensions or similar) it’s tough to come up with a robust approach here.

Either way, I am currently trying to get around this by scripting my way through the initial compiler build a bit and gluing that together with the CMake part. For my investigation (this was Clang/LLVM all the way), I found a Fuchsia-related article (which I cannot link to because new users may only use two links at most :expressionless:) extremely helpful. It opened my eye to all these .cmake files inside the source tree (under the clang subfolder) which are passed via -C to CMake and pre-populate the CMake cache a certain way.

Thanks for the input, it’s much appreciated.

Not sure this will go through, but this is the Fuchsia-related article.