CMake knows std 20, but g++9 doesn't - cmake

I have a project, which cannot be compiled by a fellow, due to an unknown call to a method from the std library.
I suspect that it's due to the fellow's g++ version (9.4.2) because the function was added in the std 20 standard. To test if that is the case I installed g++-9 (Version 9.5.0) and pointed the /usr/bin/g++ symbolic link to g++-9 and stumbled upon another issue (the question).
When I run
$ g++-9 -std=c++20
g++-9: error: unrecognized command line option ‘-std=20’; did you mean ‘-std=c2x’?
g++-9: fatal error: no input files
compilation terminated.
I get an error stating, that the std standard version 20 is unknown.
But when I try to generate the build files for an cmake project with the following line in the CMakeLists.txt:
target_compile_features(${PROJECT_NAME}
PUBLIC
cxx_std_20
)
I get no error. But when replacing the 20 with a 23:
target_compile_features(${PROJECT_NAME}
PUBLIC
cxx_std_23
)
I get the error
CMake Error at CMakeLists.txt:74 (target_compile_features):
target_compile_features The compiler feature "cxx_std_23" is not known to
CXX compiler
"GNU"
version 9.5.0.
Why is the C++20 standard unknown to g++, but known, when generating build files with cmake?
This is some sort of follow up Question:
When I try to compile my project I get the error:
error: ‘std::stringstream’ {aka ‘class std::__cxx11::basic_stringstream<char>’} has no member named ‘view’
and view was added in c++20. Can it be, that view was jet not added in c++2a?

Well... if your compiler is GCC 9.5.0, the reason why CMake says it doesn't know about C++23 is because... it doesn't?
https://en.cppreference.com/w/cpp/compiler_support
The only thing that cppreference.com's compiler support table says that GCC v9 "knows" about C++23 is "Narrowing contextual conversions in static_assert and constexpr if"
And the reason why you get "g++-9: error: unrecognized command line option ‘-std=20’; did you mean ‘-std=c2x’?" for GCC 9.5.0 is probably just because C++20 support wasn't fully implemented yet. Again, look at the compiler support table in cppreference.com. There are lots of core language features and library features for C++20 that GCC didn't implement until version 10 (some even in version 9-13 Ex. "Atomic Compare-And-Exchange with padding bits")
So just do what it told you to do and take what you get, accepting that not all of the C++20 features will be available in GCC 9.5.0.
Or upgrade you compiler :P
The reason why it works with CMake's target_compile_features(... cxx_std_20) is because... CMake handles it.
See Modules/Compiler/GNU-C.cmake:
if(CMAKE_C_COMPILER_VERSION VERSION_GREATER_EQUAL 9.1)
set(CMAKE_C23_STANDARD_COMPILE_OPTION "-std=c2x")
set(CMAKE_C23_EXTENSION_COMPILE_OPTION "-std=gnu2x")
endif()
and Modules/Compiler/GNU-CXX.cmake:
elseif(CMAKE_CXX_COMPILER_VERSION VERSION_GREATER_EQUAL 8.0)
set(CMAKE_CXX20_STANDARD_COMPILE_OPTION "-std=c++2a")
set(CMAKE_CXX20_EXTENSION_COMPILE_OPTION "-std=gnu++2a")
endif()

The name of the option for standard C++20 up to GCC 9 is -std=c++2a. According to man gcc:
c++2a
The next revision of the ISO C++ standard, planned for 2020. Support is highly experimental, and will almost certainly change in incompatible ways in future releases.
So not all features can be expected to be in there.
GCC has a tradition of providing aliases for the not yet released standards or those with incomplete support. GCC 9 only knows c++2a and that became an alias for c++20 with GCC 10.
CMake can handle this. When in doubt what CMake uses as standard (or any other option), take a look in the build directory in flags.make or build.ninja (depending on which generator you're using).

Related

CMake automatically adds -MD -MT and -MF options [duplicate]

I would like to use the IAR compiler. I noticed CMake has already have a bunch of files about this compiler:
https://github.com/jevinskie/cmake/blob/master/Modules/Compiler/IAR.cmake
From what I read the common solution is to specify manually ALL the toolchain in my CMakeLists.txt:
set(CMAKE_C_COMPILER iccarm)
set(CMAKE_CPP_COMPILER iccarm)
How CMake can link these definitions with `Modules/Compiler/IAR.cmake"?
I thought I would just have to do
include("Modules/Compiler/IAR.cmake")
What is the correct way to specify my IAR compiler?
When I do
cmake .
It still tries to use gcc instead of my IAR compiler. Why?
To select a specific compiler, you have several solutions, as exaplained in CMake wiki:
Method 1: use environment variables
For C and C++, set the CC and CXX environment variables. This method is not guaranteed to work for all generators. (Specifically, if you are trying to set Xcode's GCC_VERSION, this method confuses Xcode.)
For example:
CC=gcc-4.2 CXX=/usr/bin/g++-4.2 cmake -G "Your Generator" path/to/your/source
Method 2: use cmake -D
Set the appropriate CMAKE_FOO_COMPILER variable(s) to a valid compiler name or full path on the command-line using cmake -D.
For example:
cmake -G "Your Generator" -D CMAKE_C_COMPILER=gcc-4.2 -D CMAKE_CXX_COMPILER=g++-4.2 path/to/your/source
Method 3 (avoid): use set()
Set the appropriate CMAKE_FOO_COMPILER variable(s) to a valid compiler name or full path in a list file using set(). This must be done before any language is set (ie: before any project() or enable_language() command).
For example:
set(CMAKE_C_COMPILER "gcc-4.2")
set(CMAKE_CXX_COMPILER "/usr/bin/g++-4.2")
project("YourProjectName")
The wiki doesn't provide reason why 3rd method should be avoided...
I see more and more people who set CMAKE_C_COMPILER and other compiler-related variables in the CMakeLists.txt after the project call and wonder why this approach breaks sometimes.
What happens actually
When CMake executes the project() call, it looks for a default compiler executable and determines the way for use it: default compiler flags, default linker flags, compile features, etc.
And CMake stores path to that default compiler executable in the CMAKE_C_COMPILER variable.
When one sets CMAKE_C_COMPILER variable after the project() call, this only changes the compiler executable: default flags, features all remains set for the default compiler.
AS RESULT: When the project is built, a build system calls the project-specified compiler executable but with parameters suitable for the default compiler.
As one could guess, this approach would work only when one replaces a default compiler with a highly compatible one. E.g. replacement of gcc with clang could work sometimes.
This approach will never work for replacement of cl compiler (used in Visual Studio) with gcc one. Nor this will work when replacing a native compiler with a cross-compiler.
What to do
Never set a compiler in CMakeLists.txt.
If you want, e.g., to use clang instead of defaulted gcc, then either:
Pass -DCMAKE_C_COMPILER=<compiler> to cmake when configure the project. That way CMake will use this compiler instead of default one and on the project() call it will adjust all flags for the specified compiler.
Set CC environment variable (CXX for C++ compiler). CMake checks this variable when selects a default compiler.
(Only in rare cases) Set CMAKE_C_COMPILER variable before the project() call. This approach is similar to the first one, but makes the project less flexible.
If the ways above do not work
If on setting CMAKE_C_COMPILER in the command line CMake errors that a compiler cannot "compile a simple project", then something wrong in your environment.. or you specify a compiler incompatible for chosen generator or platform.
Examples:
Visual Studio generators work with cl compiler but cannot work with gcc.
A MinGW compiler usually requires MinGW Makefiles generator.
Incompatible generator cannot be fixed in CMakeLists.txt. One need to pass the proper -G option to the cmake executable (or select the proper generator in CMake GUI).
Cross-compiling
Cross-compiling usually requires setting CMAKE_SYSTEM_NAME variable, and this setting should normally be done in the toolchain file. That toolchain file is also responsible for set a compiler.
Setting CMAKE_SYSTEM_NAME in the CMakeLists.txt is almost always an error.
You need to create a toolchain file, and use the CmakeForceCompiler module.
Here is an example toolchain file for bare-metal ARM development with IAR:
include(CMakeForceCompiler)
set(CMAKE_SYSTEM_NAME Generic) # Or name of your OS if you have one
set(CMAKE_SYSTEM_PROCESSOR arm) # Or whatever
set(CMAKE_CROSSCOMPILING 1)
set(CMAKE_C_COMPILER iccarm) # Change the arm suffix if appropriate
set(CMAKE_TRY_COMPILE_TARGET_TYPE STATIC_LIBRARY) # Required to make the previous line work for a target that requires a custom linker file
The last line is necessary because CMake will try to compile a test program with the compiler to make sure it works and to get some version information from preprocessor defines. Without this line, CMake will use add_executable() for the test program, and you will get the error "The C compiler "XXX" is not able to compile a simple test program." This is because the test program fails to link, as it doesn't have your custom linker file (I'm assuming bare-metal development since this is what IAR is usually used for). This line tells CMake to use add_library() instead, which makes the test succeed without the linker file. Source of this workaround: this CMake mailing list post.
Then, assuming that your toolchain file is named iar-toolchain.cmake, invoke CMake like this:
cmake -DCMAKE_TOOLCHAIN_FILE=iar-toolchain.cmake .
You can call cmake like this:
cmake -DCMAKE_C_COMPILER=iccarm ...
or
cmake -DCMAKE_CXX_COMPILER=...
If you don't want to use your PC's standard compiler, you have to give CMake the path to the compiler. You do this via environment variables, a toolchain file or direct definitions in the CMake command line (see e.g. CMake Error at CMakeLists.txt:30 (project): No CMAKE_C_COMPILER could be found).
Putting the compiler's name/path into your CMakeLists.txt would stop your project from being cross-platform.
CMake does check for the compiler ids by compiling special C/C++ files. So no need to manually include from Module/Compiler or Module/Platform.
This will be automatically done by CMake based on its compiler and platform checks.
References
CMake: In which Order are Files parsed (Cache, Toolchain, …)?
CMake GitLab Commit: Add support files for C, C++ and ASM for the IAR toolchain.
IAR Systems recently published a basic CMake tutorial with examples under their GitHub profile.
I like the the idea of a generic toolchain file which works seamlessly for both Windows and Linux compilers using find_program().
The following snippet will be used for when using C and can be used similarly for CXX:
# IAR C Compiler
find_program(CMAKE_C_COMPILER
NAMES icc${CMAKE_SYSTEM_PROCESSOR}
PATHS ${TOOLKIT}
"$ENV{ProgramFiles}/IAR Systems/*"
"$ENV{ProgramFiles\(x86\)}/IAR Systems/*"
/opt/iarsystems/bx${CMAKE_SYSTEM_PROCESSOR}
PATH_SUFFIXES bin ${CMAKE_SYSTEM_PROCESSOR}/bin
REQUIRED )
For ASM, I initially got puzzled with the NAMES but then I realized that the toolchain file was made that way for working with old Assemblers shipped with XLINK:
find_program(CMAKE_ASM_COMPILER
NAMES iasm${CMAKE_SYSTEM_PROCESSOR} a${CMAKE_SYSTEM_PROCESSOR}
PATHS ${TOOLKIT}
"$ENV{PROGRAMFILES}/IAR Systems/*"
"$ENV{ProgramFiles\(x86\)}/IAR Systems/*"
/opt/iarsystems/bx${CMAKE_SYSTEM_PROCESSOR}
PATH_SUFFIXES bin ${CMAKE_SYSTEM_PROCESSOR}/bin
REQUIRED )
Also, take a look at the full toolchain file. It will work automatically for "Arm" when the tools are installed on their default locations, otherwise it is just about updating the TOOLKIT variable and the compilers for all the supported languages should adjust automatically.
If your wanting to specify a compiler in cmake then just do ...
cmake_minimum_required(VERSION 3.22)
set(CMAKE_C_COMPILER "clang")
set(CMAKE_CXX_COMPILER "clang++")
Options 1 is only used if you want to specify what compiler you want to use as default for everything that you might compile on your computer. And I don't even think it would work on windows.
Option 2 would be used if you only want to use a different temporarily.
Option 3 is used if that's the compiler that should be used for that particular project. Also option 3 would be the most cross compatible.

Building lld on Apple Silicon

I am try to build lld from LLVM version 11 (I can't use any later or master version of LLVM for the time-being) and am currently configuring with cmake ~/Downloads/lld-11.0.0.src/ -DCMAKE_INSTALL_PREFIX=$HOME/bin/llvm -DCMAKE_PREFIX_PATH=$HOME/bin/llvm -DCMAKE_BUILD_TYPE=Release -G Ninja but ninja install then fails with 20 errors that I think are all standard library related (such as "unknown type name 'constexpr'" and "no template named 'underlying_type_t' in namespace 'std'; did you mean 'underlying_type'?").
The compiler cmake is using by default is Apple Clang 12 which came with my system (or was installed automatically). What other flags should I pass to cmake to get this working? Or do I need to use a different compiler? LLVM 11 configures and builds fine with the same cmake flags.
For anyone else experiencing similar issues: Building LLVM, lld and clang from the monorepo all in one go worked. I had to add -DLLVM_ENABLE_PROJECTS="clang;lld" to the cmake command.

Error during cmake build : CXX compiler must support Cilk

I am trying to install cilk++ according to this website and am at the steps in section "Cilk Plus Runtime". When I go to build, I get the following output:
$ cmake -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ -DCMAKE_INSTALL_PREFIX=./install ..
CMake Error at CMakeLists.txt:132 (message):
CXX compiler must support Cilk.
-- Configuring incomplete, errors occurred!
See also "/Users/anthonymcknight/Documents/cubing/bfs/lab4/cilk/cilkrts-0.1.2/build/CMakeFiles/CMakeOutput.log".
See also "/Users/anthonymcknight/Documents/cubing/bfs/lab4/cilk/cilkrts-0.1.2/build/CMakeFiles/CMakeError.log".
I thought clang and clang++ (which I checked with --version are indeed installed) would be sufficient. Do I need to update clang and clang++? There are no troubleshooting steps on the instructions website, so I'm not sure what I need to do to finally get cilk++ up and running on my laptop.
Thanks in advance,
Anthony
Expanding on my comment:
When you configure this Cilk Plus Runtime with CMake, CMake first verifies the compiler by attempting to compile a simple test program (see here). If the compilation fails, CMake prints the error you see:
CMake Error at CMakeLists.txt:132 (message):
CXX compiler must support Cilk.
On the Intel Cilk Plus runtime Github page (cilkrts), it has some compiler requirements listed for those trying to build this library:
You need the CMake tool and a C/C++ compiler that supports the Cilk language extensions. The requirements for each operating systems are:
Common: CMake 3.4.3 or later Make tools such as make
Linux: Tapir/LLVM compiler, or GCC* 4.9.2 or later (depracated), or Cilk-enabled branch of Clang*/LLVM* (http://cilkplus.github.io), or Intel(R) C++ Compiler v12.1 or later (depracated)
OS X: Tapir/LLVM compiler, or Cilk-enabled branch of Clang*/LLVM* (http://cilkplus.github.io), or Intel C++ Compiler v12.1 or later (depracated)
Since you are using Clang as your compiler, be sure it is a Cilk-enabled branch of Clang, as specified in the requirements. Or, you can try to use the Tapir/LLVM compiler.

CMake idiom for overcoming libstdc++ filesystem weirdness?

If you build C++14 code with G++ and libstdc++, there's a library named libstdc++fs, which is separate from the rest of libstdc++, and contains the code for std::experimental::filesystem. If you don't link against it, you'll get undefined references.
The "trick" I'm using for overcoming this right now is:
if ("${CMAKE_CXX_COMPILER_ID}" STREQUAL "GNU")
set(CXX_FILESYSTEM_LIBRARIES "stdc++fs")
endif()
and later:
target_link_libraries(my_target PUBLIC ${CXX_FILESYSTEM_LIBRARIES})
but - I don't like having to place this code in every project I work on. Is there a simpler or more standard idiom I could use? Some way this will all happen implicitly perhaps, with some CMake behind-the-scences magic?
tl;dr: Nothing right now, wait for a newer CMake version
As #Pedro graciously points out, this is a known problem, and there is an open issue about it at KitWare's GitLab site for CMake:
Portable linking for C++17 std::filesystem
If using CMAKE_CXX_STANDARD=17 and std::filesystem, GCC requires linking of an extra library: stdc++fs. ... If C++17 is enabled, would it be worth automatically linking to stdc++fs for GCC versions which require this? Likewise for any quirks in other compilers or libraries.
The KitWare issue is about C++17, for which apparently you still need the separate extra library (i.e. it's not just because of the "experimentality" in C++14). Hopefully we'll see some traction on this matter - but
Note: If you're experiencing this problem with C++17's std::filesystem, you're in luck - that code is built into libstdc++ beginning with GCC 9, so if you're using g++ 9 or later, and std::filesystem, you should no longer experience this problem.

Error in mediactrl_am.cpp while building wxwidgets 3.0.3 with llvm 5.0.0 target x86_64-w64-windows-gnu

I'v recently compiled wxWidgets 3.0.3 with mingw-w64 7.2.0, but due some problems with exception handling now I'm trying recompile them with llvm 5.0.0 (using x86_64-w64-windows-gnu target, standard library from mingw-w64 7.2.0, 64 bit, seh, posix threads) which has not those problems.
I have not find instructions how to build current stable version (3.0.3) of wxWidgets with Clang on Windows. So I'm trying a command like
mingw32-make.exe -f makefile.gcc MONOLITHIC=1 SHARED=1 BUILD=debug CXXFLAGS=" -fexceptions -fasynchronous-unwind-tables -fnon-call-exceptions -std=gnu++11 -pthread " LDFLAGS=" -fexceptions -fasynchronous-unwind-tables -fnon_call_exceptions -pthread " CC="clang -target x86_64-w64-windows-gnu" CXX="clang++ -target x86_64-w64-windows-gnu" COMPILER_PREFIX="clang"
in ..\build\msw subdirectory to build one of the possible configurations.
(With mingw-w64 I used also LDFLAGS=" -Wl,--allow-multiple-definition ", possible here will be problems with multiple symbols too. I've also pathched source code as I had problems with wxPrintf)
The first error I have:
../../src/msw/mediactrl_am.cpp:2234:10: error: case value evaluates to
4294966687, which cannot be narrowed to type 'DISPID' (aka 'long')
[-Wc++11-narrowing]
case 0xfffffd9f: // readystatechange in IActiveMovie2 and IMediaPlayer
^
1 error generated.
My account on wxWidgets forum not activated yet, so I ask here.
May be somebody knows correct way how to repair this issue?
The obvious fix for this particular problem seems to be to replace this value with -609.
However I need to warn you that, to the best of my knowledge, nobody has compiled wxMSW using clang so far (even though clang can be used for compiling wxGTK and wxOSX, of course), so you may well run into other, less trivial, problems later. I'd also recommend trying to compile the latest git master instead of 3.0.3 as any non-trivial changes that might be required for clang build are unlikely to be done in the stable 3.0 branch.