Detect 32-bit x86 processor in CMakeList.txt? - cmake

We are catching errors in our CMake makefiles due to lack of -fPIC. Her's one from a ci20 MIPS dev-board:
...
[ 92%] Built target cryptopp-object
Scanning dependencies of target cryptopp-shared
Scanning dependencies of target cryptopp-static
Linking CXX static library libcryptopp.a
Linking CXX shared library libcryptopp.so
/usr/bin/ld: CMakeFiles/cryptopp-object.dir/cryptlib.cpp.o: relocation R_MIPS_HI16 against
`a local symbol' can not be used when making a shared object; recompile with -fPIC
CMakeFiles/cryptopp-object.dir/cryptlib.cpp.o: could not read symbols: Bad value
collect2: ld returned 1 exit status
The project's policy is to us PIC everywhere except 32-bit x86 due to register pressures. That means x86_64, ARM-32, Aarch32, Aarch64, MIPS, MIPS64, UltraSparc, etc get PIC.
I believe the target processor is provided in CMAKE_SYSTEM_PROCESSOR. The problem I am having is the docs don't tell me the values, so I can't figure out how to craft a "not 32-bit x86" test.
How do I detect 32-bit x86 processor in CMakeList.txt?
Even better, I would like to see a comprehensive list of processors that CMake sets CMAKE_SYSTEM_PROCESSOR to. If anyone has the list, then it would be great to provide it.

I probably would build something around the compiler.
A close approximation using existing variables/modules would be:
include(TestBigEndian)
if (NOT WIN32)
TEST_BIG_ENDIAN(_bigendian)
if((CMAKE_SIZEOF_VOID_P GREATER 4) OR (_bigendian))
message(
STATUS "Setting ${CMAKE_CXX_COMPILE_OPTIONS_PIC} "
"for machine ${CMAKE_HOST_SYSTEM_PROCESSOR}"
)
set(CMAKE_POSITION_INDEPENDENT_CODE 1)
endif()
endif()
In short what I have done:
WIN32 is also valid for 64 Bit Windows compilers/environments
CMAKE_SIZEOF_VOID_P GREATER 4 checks for "greater then 32 Bit"
The last is the biggest assumption: take all little endian processors as Intel/AMD based
Used more generic CMAKE_POSITION_INDEPENDENT_CODE to set -fPIC
I admit a more accurate method would be to build something around a pre-defined macros test.
Edit: Added "Predefined Macros Check" Alternative
Here is the more precise check for predefined macros:
include(CheckCXXSourceCompiles)
if (CMAKE_CXX_COMPILE_OPTIONS_PIC)
set(
_preDefMacrosX86
__i386 __i386__ __i486__ __i586__ __i686__
_M_I86 _M_IX86 __X86__ _X86_ __THW_INTEL__
__I86__ __INTEL__ __386
)
set(_code "void main() {}")
foreach(_macro IN LISTS _preDefMacrosX86)
set(
_code
"${_code}\n\#ifdef ${_macro}\n\#error ${_macro} is defined\n\#endif"
)
endforeach()
CHECK_CXX_SOURCE_COMPILES("${_code}" _canCompileX86DoesFailCheck)
if((CMAKE_SIZEOF_VOID_P GREATER 4) OR (_canCompileX86DoesFailCheck))
message(STATUS "Setting ${CMAKE_CXX_COMPILE_OPTIONS_PIC}")
set(CMAKE_POSITION_INDEPENDENT_CODE 1)
endif()
endif()
References
How to detect if 64 bit MSVC with cmake?
Detecting CPU architecture compile-time

I believe this performs the detection on nearly everything except Windows. Windows does not consume -fPIC, so it does not matter to me. The pieces were glued together from three Stack Overflow answers.
# Stop hiding the damn output...
set(CMAKE_VERBOSE_MAKEFILE on)
# Enable PIC for all targets except Windows and 32-bit x86
if (NOT (WINDOWS OR WINDOWS_STORE OR WINDOWS_PHONE))
set (UNAME_CMD "uname")
set (UNAME_ARG "-m")
execute_process(COMMAND ${UNAME_CMD} ${UNAME_ARG}
WORKING_DIRECTORY ${PROJECT_SOURCE_DIR}
RESULT_VARIABLE UNAME_RESULT
OUTPUT_VARIABLE UNAME_MACHINE)
# Use Regex; match i386, i486, i586 and i686
IF (NOT (${UNAME_MACHINE} MATCHES "i.86"))
# message(STATUS "Setting -fPIC for machine ${UNAME_MACHINE}")
if (CMAKE_VERSION VERSION_LESS 2.8.12)
add_definitions(-fPIC)
else()
add_compile_options(-fPIC)
endif()
endif()
endif()
You get the machine with uname -m, and its mostly accurate, even on OS X. For example, on OS X, uname -p returns i386 while uname -m returns x86_64. I seem to recall 10.6 or 10.7 was a little flaky as the transition was being made to 64-bit Macs.
You get the processor with uname -p sometimes, but it fails on many dev-boards. For example my ci20 dev-board returns "mips" for the machine and "unknown" for the processor. Another example is my LeMaker HiKey. It returns "aarch64" for the machine and "unknown" for the processor.
I'd still like to see the list of processors provided by Cmake.

Related

Use non-default linker (lld, mold, gold) with CMake [duplicate]

I want to setup a custom toolchain with CMake. I've set the compiler but I don't know how to set the linker. This error is reported because CMake try to use the compiler to link:
The C compiler "xgcc.exe" is not able to compile a simple test program.
Here there is a snippet of my toolchain file
# specify the cross compiler
INCLUDE(CMakeForceCompiler)
SET(CMAKE_C_COMPILER xgcc.exe)
SET(CMAKE_CXX_COMPILER xgcc.exe)
#CMAKE_FORCE_C_COMPILER(xgcc.exe GNU)
#CMAKE_FORCE_CXX_COMPILER(xgcc.exe GNU)
I've tried to force the compiler but the linker problem will not be solved.
The link command line is set in Modules/CMake{C,CXX,Fortran}Information.cmake and defaults to using the compiler, not CMAKE_LINKER (see source code). This can be changed by replacing the rule that builds the link command line, which lives in variables CMAKE_CXX_LINK_EXECUTABLE (and friends). NB that variable does not indicate the path to the linker executable; it says how to link an executable!
One approach is to set that rule to use the linker, e.g.
cmake -DCMAKE_LINKER=/path/to/linker -DCMAKE_CXX_LINK_EXECUTABLE="<CMAKE_LINKER> <FLAGS> <CMAKE_CXX_LINK_FLAGS> <LINK_FLAGS> <OBJECTS> -o <TARGET> <LINK_LIBRARIES>"
See also this post from CMake mailing list and this one - this also makes a natural place to prepend a linker modifier to another linker.
As Mabraham points out, CMake calls the compiler to do the linking. So, by far the simplest solution to this is to LET IT, and instead tell the compiler to run a different linker when called.
Which, as noted in this other answer — but now it's even a documented option in gcc --help=common — is as easy as:
cmake -DCMAKE_CXX_FLAGS="-fuse-ld=lld"
g++ or clang++ will get passed the -fuse-ld=lld1 flag on every call, and when they do any linking they'll use the specified command instead of the built-in default. Easy-peasy, and CMake need not concern itself with such things at all.
(BTW, the option is parsed (-f) (use-ld) (=) (lld), there's no "fuse" option to gcc.)
Notes
When using Clang, lld can be replaced with whatever other linker command you want to use, like ld.exe, ld.gold, mingw32/bin/ld.exe, etc.
GCC isn't as flexible, its -fuse-ld only accepts one of three possible arguments: lld, bfd, or gold. It will invoke the first matching ld.foo executable it finds on the PATH. (Thanks to bviktor for pointing out GCC's limitations for alternate linker selection.)
CMake only gives you direct control over the compiler for each language. To call the linker, it goes through the configured compiler. This means that there is no universal way to set the linker in CMake, you must configure your compiler to use the linker you intend.
Such flags need to be set before CMake's compiler detection routines run because it will try to compile a test binary. The best way to do this is by creating a toolchain file. The best way to set these flags in the toolchain file is like so:
# e.g. to use lld with Clang
set(CMAKE_EXE_LINKER_FLAGS_INIT "-fuse-ld=lld")
set(CMAKE_MODULE_LINKER_FLAGS_INIT "-fuse-ld=lld")
set(CMAKE_SHARED_LINKER_FLAGS_INIT "-fuse-ld=lld")
These three variables control the (default) set of linker flags for executables, loadable modules, and shared libraries, respectively. There is no need to handle CMAKE_STATIC_LINKER_FLAGS_INIT (for static libraries) here because the archiver is invoked, rather than the linker.
You can then set the toolchain file when you first run CMake by setting -DCMAKE_TOOLCHAIN_FILE=/path/to/toolchain.cmake at the command line. As of CMake 3.21, you will be able to pass --toolchain /path/to/toolchain.cmake instead (which is entirely equivalent, but a little less typing).
Set the variable ${CMAKE_LINKER} either in CMakeCache.txt or after ccmake . under advanced options.
I have to use CMAKE_CXX_LINK_EXECUTABLE, CMAKE_C_LINK_EXECUTABLE variable:
SET(CMAKE_C_LINK_EXECUTABLE "c:\\MoSync\\bin\\pipe-tool.exe")
I had success with doing
add_link_options("-fuse-ld=lld")
It is a variation on the previous answers here. The difference is the CMake command I use to set the flag.
Adding it to CMAKE_CXX_FLAGS has the disadvantage of then also having to add -Wno-unused-command-line-argument as the flags get also added to compilation commands, not only to linking ones.
The disadvantage of CMAKE_SHARED_LINKER_FLAGS is that you have to add it multiple times, to _SHARED_, _EXE_, and maybe I forgot something.
Here is a CMake function which sets linker based on some predefined arbitrary rules (Clang -> lld-version or lld, GCC -> gold).
The important parts:
Search for lld-version which matches the Clang compiler version (ex. lld-13 if Clang 13.x.x is used), falls back to lld if not found
add_link_options("-fuse-ld=lld-${CLANG_VERSION_MAJOR}")
Use all system threads when linker is set to gold:
add_link_options("-fuse-ld=gold;LINKER:--threads,--thread-count=${HOST_PROC_COUNT}")
The example is a bit too long because of comments, logs and custom logic, but it is self-contained and could be useful staring point for beginners.
function(select_best_linker) #lld for Clang and GNU gold for GCC
if (UNIX AND NOT APPLE)
include(ProcessorCount)
ProcessorCount(HOST_PROC_COUNT)
if(${CMAKE_CXX_COMPILER_ID} MATCHES Clang)
# By default LLD uses all system threads.
# This could be tweaked for versions 11+ (--threads=1), but cannot be disabled for older versions
# add_link_options("-fuse-ld=lld-${CLANG_VERSION_MAJOR};LINKER:--threads=${HOST_PROC_COUNT}") #LLD>=11
# add_link_options("-fuse-ld=lld;LINKER:--threads")#LLD <= 10 this is the default state
string(REPLACE "." ";" VERSION_LIST ${CMAKE_CXX_COMPILER_VERSION})
list(GET VERSION_LIST 0 CLANG_VERSION_MAJOR) #extract major compiler version
find_program(LLD_PROGRAM_MATCH_VER lld-${CLANG_VERSION_MAJOR}) #search for lld-13 when clang 13.x.x is used
find_program(LLD_PROGRAM lld) #else find default lld
if (LLD_PROGRAM_MATCH_VER) #lld matching compiler version
message(STATUS "Set linker to LLD (multi-threaded): ${LLD_PROGRAM_MATCH_VER}")
add_link_options("-fuse-ld=lld-${CLANG_VERSION_MAJOR}")
elseif(LLD_PROGRAM) #default lld
message(STATUS "Set linker to LLD (multi-threaded): ${LLD_PROGRAM}")
add_link_options("-fuse-ld=lld")
endif(LLD_PROGRAM_MATCH_VER)
elseif(${CMAKE_CXX_COMPILER_ID} MATCHES GNU)
find_program(GNU_GOLD_PROGRAM gold)
if (GNU_GOLD_PROGRAM)
message(STATUS "Set linker to GNU gold: ${GNU_GOLD_PROGRAM}, using threads: ${HOST_PROC_COUNT}")
add_link_options("-fuse-ld=gold;LINKER:--threads,--thread-count=${HOST_PROC_COUNT}")
endif(GNU_GOLD_PROGRAM)
endif(${CMAKE_CXX_COMPILER_ID} MATCHES Clang)
endif(UNIX AND NOT APPLE)
endfunction(select_best_linker)
Tested on:
Ubuntu 20.04
CMake 3.16.3
GCC 9.4.0
Clang-12
Clang-13
GNU gold (GNU Binutils 2.37) 1.16
LLD 10.0.0 (compatible with GNU linkers)
Ubuntu LLD 13.0.1 (compatible with GNU linkers)
For completeness, another full-proof option is to just link /usr/bin/ld to ld.gold by running
sudo ln -sf /usr/bin/x86_64-linux-gnu-ld.gold /usr/bin/ld
as suggested here
There is another way to do it, gcc has a "-fuse-ld" option, you can set LINKER_FLAGS in CMakeLists.txt like these:
set(CMAKE_SHARED_LINKER_FLAGS "${CMAKE_SHARED_LINKER_FLAGS} -fuse-ld=lld")
set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -fuse-ld=lld")
then the custom specified linker should be invoked.

Why is CMAKE_CXX_FLAGS empty?

Consider the following CMakeLists.txt file:
project(MyProject)
cmake_minimum_required(VERSION 3.16)
add_executable(MyApp main.cpp)
message(${CMAKE_CXX_FLAGS})
Now, running this:
$ cmake --DCMAKE_BUILD_TYPE=Debug <path_to_directory>
I get an error that the CMAKE_CXX_FLAGS is not set. (more accurately - message is called with wrong number of arguments).
I try to understand what exactly the CMAKE_BUILD_TYPE is causing by default - i.e. how it translates to compiler options/flags.
After building the project, I can clearly see that when running with CMAKE_BUILD_TYPE set to Release, the file is smaller (around a third) than when running with it set to Debug, so clearly it has some effect.
First of all, you must always call cmake_minimum_required before any other commands.
cmake_minimum_required(VERSION 3.16)
project(MyProject)
add_executable(MyApp main.cpp)
message(STATUS "CMAKE_CXX_FLAGS = ${CMAKE_CXX_FLAGS}")
Now, to answer your question...
Why is CMAKE_CXX_FLAGS empty?
Because it is intended to be set on the command line by a user of your build. This is the place where you would inject flags that apply to all C++ compiler invocations, regardless of configuration.
I try to understand what exactly the CMAKE_BUILD_TYPE is causing by default - i.e. how it translates to compiler options/flags.
On a multi configuration generator, like Visual Studio or Xcode, it does nothing. On a single configuration generator (like Makefiles or Ninja), the variable sets the active config. That means that all the variables listed in the documentation with <CONFIG> in the name get ${CMAKE_BUILD_TYPE} substituted in for <CONFIG> and used alongside their non-<CONFIG> variants.
There are four configurations that CMake provides:
Debug -- don't optimize and ensure debug symbols are enabled. On GCC this is -g.
Release -- full optimization, disable assert(). On GCC this is -O3 -DNDEBUG.
MinSizeRel -- release mode, but optimize for size. On GCC this is -Os -DNDEBUG.
RelWithDebInfo -- release mode, but optimize less to facilitate debugging. Include debug symbols. On GCC this is -O2 -g -DNDEBUG.

MacOS, CMake and OpenMP

I am using the newest CMake (3.9.3) from Homebrew along with LLVM 5.0.0 also from Brew, because Clang here has OpenMP support.
This worked in CMake 3.8.2 with LLVM 5.
In my CMakeLists.txt I have
find_package( OpenMP )
and later I want to do
if( OpenMP_CXX_FOUND )
However CMake doesn't seem to pick up on the find_package directive.
I run CMake with
cmake .. -DCMAKE_BUILD_TYPE=Debug -DCMAKE_CXX_COMPILER=clang++ -DCMAKE_C_COMPILER=clang -DUSE_WERROR=ON
where I have checked that clang and clang++ points correctly to /usr/local/opt/llvm/bin/clang and /usr/local/opt/llvm/bin/clang++
All I get is these two lines:
-- Could NOT find OpenMP_C (missing: OpenMP_C_FLAGS OpenMP_C_LIB_NAMES) (found version "1.0")
-- Could NOT find OpenMP_CXX (missing: OpenMP_CXX_FLAGS OpenMP_CXX_LIB_NAMES) (found version "1.0")
If I set OpenMP_C_FLAGS myself (with -DOpenMP_C_FLAGS=-fopenmp=libomp) it changes the error to
-- Could NOT find OpenMP_C (missing: OpenMP_C_LIB_NAMES) (found version "3.1")
Notice that it changes the version number, so it must be finding something, right?
What am I missing for this to work properly?
Okay, it seem that inside the FindOpenMP.cmake supplied by CMake we do a try_compile, which fails silently (because we do it a lot of times and most of them will fail, this makes sense). However, with Clang a -Werror flag is supplied, which fails because of an unused command line argument. I can thus add:
if(APPLE)
if(CMAKE_C_COMPILER_ID STREQUAL "Clang")
set(OpenMP_C_FLAG "-fopenmp=libomp -Wno-unused-command-line-argument")
endif()
if(CMAKE_CXX_COMPILER_ID STREQUAL "Clang")
set(OpenMP_CXX_FLAG "-fopenmp=libomp -Wno-unused-command-line-argument")
endif()
endif()
to my project because I know that -fopenmp=libomp will work for this Clang.
Is this the right way of doing it?
The message basically tells you that you have to provide the path to the libraries and the names of the libraries. The following example should fix your problem (see also find_package(OpenMP)). Note that I use the brew installation using the command "brew install llvm". The first four lines are just for completeness.
set(CMAKE_C_COMPILER "/usr/local/Cellar/llvm/5.0.1/bin/clang")
set(CMAKE_CXX_COMPILER "/usr/local/Cellar/llvm/5.0.1/bin/clang++")
set(OPENMP_LIBRARIES "/usr/local/Cellar/llvm/5.0.1/lib")
set(OPENMP_INCLUDES "/usr/local/Cellar/llvm/5.0.1/include")
OPTION (USE_OpenMP "Use OpenMP to enamble <omp.h>" ON)
# Find OpenMP
if(APPLE AND USE_OpenMP)
if(CMAKE_C_COMPILER_ID MATCHES "Clang")
set(OpenMP_C "${CMAKE_C_COMPILER}")
set(OpenMP_C_FLAGS "-fopenmp=libomp -Wno-unused-command-line-argument")
set(OpenMP_C_LIB_NAMES "libomp" "libgomp" "libiomp5")
set(OpenMP_libomp_LIBRARY ${OpenMP_C_LIB_NAMES})
set(OpenMP_libgomp_LIBRARY ${OpenMP_C_LIB_NAMES})
set(OpenMP_libiomp5_LIBRARY ${OpenMP_C_LIB_NAMES})
endif()
if(CMAKE_CXX_COMPILER_ID MATCHES "Clang")
set(OpenMP_CXX "${CMAKE_CXX_COMPILER}")
set(OpenMP_CXX_FLAGS "-fopenmp=libomp -Wno-unused-command-line-argument")
set(OpenMP_CXX_LIB_NAMES "libomp" "libgomp" "libiomp5")
set(OpenMP_libomp_LIBRARY ${OpenMP_CXX_LIB_NAMES})
set(OpenMP_libgomp_LIBRARY ${OpenMP_CXX_LIB_NAMES})
set(OpenMP_libiomp5_LIBRARY ${OpenMP_CXX_LIB_NAMES})
endif()
endif()
if(USE_OpenMP)
find_package(OpenMP REQUIRED)
endif(USE_OpenMP)
if (OPENMP_FOUND)
include_directories("${OPENMP_INCLUDES}")
link_directories("${OPENMP_LIBRARIES}")
set (CMAKE_C_FLAGS "${CMAKE_C_FLAGS} ${OpenMP_C_FLAGS}")
set (CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} ${OpenMP_CXX_FLAGS}")
# set (CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} ${OpenMP_EXE_LINKER_FLAGS}")
endif(OPENMP_FOUND)
You might want to set e.g. set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -lpthread") such that the linker automatically detects the appropriate pthread library (see pthread and wiki).
Apparently, case is important. For an unrelated project I can make it work with
find_package ( OPENMP REQUIRED )
This didn't work:
find_package ( OpenMP REQUIRED )
With that directive, no need for setting all the other flags by hand.
cmake 3.13.2, clang-1000.11.45.5 (High Sierra)
Maybe it's a CMake version thing, I come up with a slightly different solution with Franzi's.
I also use brew install libomp on my machine. It seems like OpenMP_CXX_FLAGS is used for compiling project source code instead of compiling the omp (the flag is stored in the omp target and will be populated by command target_link_libraries).
Besides that, OpenMP_CXX_LIB_NAMES shouldn't have prefix lib because it will cause an error like -llibomp not found, where -lomp should be used instead.
I also noticed that CMAKE_C_COMPILER_ID is AppleClang instead of Clang if I put project(playground) after cmake_minimum_required. In reverse, it's Clang, quite annoying and I don't know why.
Xpreprocessor used here is because apple clang doesn't ship with OpenMP and this flag tells the compiler to look for pragma (preprocessor expansion) elsewhere. In our case, it's the header files in the include path where the libomp is installed.
cmake_minimum_required(VERSION 3.12)
project(playground)
if(APPLE)
set(CMAKE_C_COMPILER clang)
set(CMAKE_CXX_COMPILER clang++)
if(CMAKE_C_COMPILER_ID MATCHES "Clang\$")
set(OpenMP_C_FLAGS "-Xpreprocessor -fopenmp")
set(OpenMP_C_LIB_NAMES "omp")
set(OpenMP_omp_LIBRARY omp)
endif()
if(CMAKE_CXX_COMPILER_ID MATCHES "Clang\$")
set(OpenMP_CXX_FLAGS "-Xpreprocessor -fopenmp")
set(OpenMP_CXX_LIB_NAMES "omp")
set(OpenMP_omp_LIBRARY omp)
endif()
endif()
find_package(OpenMP REQUIRED)
add_executable(helloworld helloworld.cxx)
target_link_libraries(helloworld PRIVATE OpenMP::OpenMP_CXX)
Here's my helloworld
#include <cstdio>
#include <thread>
#include <sstream>
int main(void)
{
#pragma omp parallel
{
std::stringstream ss;
ss << std::this_thread::get_id();
printf("%s, Hello, world.\n", ss.str().c_str());
}
return 0;
}
output is,
0x700002dc8000, Hello, world.
0x10a17d5c0, Hello, world.
0x7000045d1000, Hello, world.
0x7000055d7000, Hello, world.
0x700005dda000, Hello, world.
0x7000035cb000, Hello, world.
0x7000065dd000, Hello, world.
0x700003dce000, Hello, world.
0x700007de6000, Hello, world.
0x700004dd4000, Hello, world.
0x7000075e3000, Hello, world.
0x700006de0000, Hello, world.
With recent versions of CMake (3.18, didn't work with 3.14) and a fresh installation of MacOS (with developer CL tools installed, of course), brew install libomp was the only action needed to make things work.
MacOS Ventura
cmake: /usr/local/Cellar/cmake/3.25.1
OpenMP: /usr/local/Cellar/libomp/15.0.7
llvm: /usr/local/Cellar/llvm/15.0.7_1
above solution worked after setting compiler directories and libomp directories to the correct values
with the change:
set(OpenMP_C_FLAGS "-fopenmp=libomp")
for both the clang and clangxx sections

How to determine platforms like ARM, MIPS and IA32?

Something is sideways in our CmakeFileList.txt file. Its trying to build an IA32 component on an ARM platform. I'm trying to fix the issue.
The file in question was filtered-out from the GLOB, which is named rdrand.cpp:
list(REMOVE_ITEM cryptopp_SOURCES
...
${CMAKE_CURRENT_SOURCE_DIR}/rdrand.cpp
...
${cryptopp_SOURCES_TEST}
)
set(cryptopp_SOURCES
Now I am trying to add rdrand,cpp back in for IA32 platforms. According to Building c++ project on Windows with CMake, Clang and Ninja (not a good fit, but it has useful information) and CMakePlatformId.h.in, it looks like I need a predicate using ARCHITECTURE_ID and "X86", "X32", "X64" or "x64" (not a dup, the x is lowercase instead of uppercase).
Here's my attempt to create the predicate:
# http://github.com/weidai11/cryptopp/issues/419
if (${ARCHITECTURE_ID} == "X86" OR ${ARCHITECTURE_ID} == "X32" OR ${ARCHITECTURE_ID} == "X64" )
list(APPEND cryptopp_SOURCES ${CMAKE_CURRENT_SOURCE_DIR}/rdrand.cpp)
endif()
The results below are from a BeagleBoard with Cmake 3.5.2. Neither ==, =,STREQUAL seems to work:
CMake Error at CMakeLists.txt:310 (if):
if given arguments:
"==" "X86" "OR" "==" "X32" "OR" "==" "X64"
Unknown arguments specified
And:
$ cmake .
CMake Error at CMakeLists.txt:310 (if):
if given arguments:
"STREQUAL" "X86" "OR" "STREQUAL" "X32" "OR" "STREQUAL" "X64"
Unknown arguments specified
My attempts to search for how to use ARCHITECTURE_ID are nearly useless. I can't find an example or the docs on Cmake's site. Adding quotes around "${ARCHITECTURE_ID}" did not help; nor did removing the braces to denote a variable ARCHITECTURE_ID.
I also tried to use CMAKE_SYSTEM_PROCESSOR and other related defines, but Cmake mostly returns "unknown" for them. Its not very helpful to say the least.
How do I use ARCHITECTURE_ID to identify IA32 platforms? Or, is there something else I should be using in this instance?
Thanks in advance.
Here's what we do in our GNUmakefile. Make is not a build system, so we have to do the heavy lifting:
IS_X86 := $(shell uname -m | $(EGREP) -v "x86_64" | $(EGREP) -i -c "i.86|x86|i86")
IS_X64 := $(shell uname -m | $(EGREP) -i -c "(_64|d64)")
...
# Need RDRAND for X86/X64/X32
ifeq ($(IS_X86)$(IS_X32)$(IS_X64),000)
SRCS := $(filter-out rdrand.cpp, $(SRCS))
endif
I don't think a variable named ARCHITECTURE_ID does exist in CMake to query. That's probably the reason why you can't find any hints in CMake's documentation. It's only used in CMakePlatformId.h to fill MSVC specific internal variable like MSVC_CXX_ARCHITECTURE_ID.
/* For windows compilers MSVC and Intel we can determine
the architecture of the compiler being used. This is because
the compilers do not have flags that can change the architecture,
but rather depend on which compiler is being used
*/
What you are actually looking for is the cmake_host_system_information()command. The problem there is, that it does not export all the information it actually has. I'm thinking that to be a missing feature and probably will make a pull request for CMake's source Git over the next days to extend its functionality, but that won't help you for the near future.
If you have CMake's source code on the system(s) in question you could run one of the tests
$ cmsysTestscxx testSystemInformation
to see what system information CMake actually has.
𝓝𝓸𝓽𝓮: Querying the host system won't help when cross-compiling or e.g. compiling for 32 Bit on a 64 Bit machine (that could also be a possible flaw in your GNUMakefile example).
To answer your question about the if statement, this can simply be solved by an Regular Expression:
cmake_minimum_required(VERSION 2.4)
project(TestArchitectureId)
if (ARCHITECTURE_ID MATCHES "^(X86|X32|X64|x64)$" )
message(STATUS "Hello ${CMAKE_MATCH_1}")
endif()
Otherwise isn't this somewhat related to Detect 32-bit x86 processor in CMakeList.txt?
Alternatives
CMake itself uses
if(NOT CMAKE_SYSTEM_PROCESSOR STREQUAL "ia64")
or
if(NOT CMAKE_GENERATOR MATCHES "IA64")
or - even this may be going the extra mile - call try_compile() with rdrand.cpp:
# Choose a configuration for our compiler tests
if (NOT CMAKE_CONFIGURATION_TYPES AND
NOT CMAKE_NO_BUILD_TYPE)
set(CMAKE_TRY_COMPILE_CONFIGURATION "${CMAKE_BUILD_TYPE}")
else()
set(CMAKE_TRY_COMPILE_CONFIGURATION RelWithDebInfo)
endif()
set(CMAKE_TRY_COMPILE_TARGET_TYPE STATIC_LIBRARY)
string(TOUPPER "${CMAKE_TRY_COMPILE_CONFIGURATION}" cryptopp_TRY_COMPILE_CONFIGURATION)
set(CMAKE_REQUIRED_FLAGS "${CMAKE_CXX_FLAGS}" "${CMAKE_CXX_FLAGS_${cryptopp_TRY_COMPILE_CONFIGURATION}}")
get_directory_property(CMAKE_REQUIRED_INCLUDES INCLUDE_DIRECTORIES)
get_directory_property(CMAKE_REQUIRED_DEFINITIONS COMPILE_DEFINITIONS)
if (CMAKE_REQUIRED_DEFINITIONS)
string(REPLACE ";" ";-D" CMAKE_REQUIRED_DEFINITIONS "-D${CMAKE_REQUIRED_DEFINITIONS}")
endif()
try_compile(
cryptopp_RDRAND_WORKS
${CMAKE_CURRENT_BINARY_DIR}
SOURCES ${CMAKE_CURRENT_SOURCE_DIR}/rdrand.cpp
CMAKE_FLAGS
-DCOMPILE_DEFINITIONS:STRING=${CMAKE_REQUIRED_FLAGS}
-DINCLUDE_DIRECTORIES:STRING=${CMAKE_REQUIRED_INCLUDES}
COMPILE_DEFINITIONS
${CMAKE_REQUIRED_DEFINITIONS}
)

CMake: use a custom linker

I want to setup a custom toolchain with CMake. I've set the compiler but I don't know how to set the linker. This error is reported because CMake try to use the compiler to link:
The C compiler "xgcc.exe" is not able to compile a simple test program.
Here there is a snippet of my toolchain file
# specify the cross compiler
INCLUDE(CMakeForceCompiler)
SET(CMAKE_C_COMPILER xgcc.exe)
SET(CMAKE_CXX_COMPILER xgcc.exe)
#CMAKE_FORCE_C_COMPILER(xgcc.exe GNU)
#CMAKE_FORCE_CXX_COMPILER(xgcc.exe GNU)
I've tried to force the compiler but the linker problem will not be solved.
The link command line is set in Modules/CMake{C,CXX,Fortran}Information.cmake and defaults to using the compiler, not CMAKE_LINKER (see source code). This can be changed by replacing the rule that builds the link command line, which lives in variables CMAKE_CXX_LINK_EXECUTABLE (and friends). NB that variable does not indicate the path to the linker executable; it says how to link an executable!
One approach is to set that rule to use the linker, e.g.
cmake -DCMAKE_LINKER=/path/to/linker -DCMAKE_CXX_LINK_EXECUTABLE="<CMAKE_LINKER> <FLAGS> <CMAKE_CXX_LINK_FLAGS> <LINK_FLAGS> <OBJECTS> -o <TARGET> <LINK_LIBRARIES>"
See also this post from CMake mailing list and this one - this also makes a natural place to prepend a linker modifier to another linker.
As Mabraham points out, CMake calls the compiler to do the linking. So, by far the simplest solution to this is to LET IT, and instead tell the compiler to run a different linker when called.
Which, as noted in this other answer — but now it's even a documented option in gcc --help=common — is as easy as:
cmake -DCMAKE_CXX_FLAGS="-fuse-ld=lld"
g++ or clang++ will get passed the -fuse-ld=lld1 flag on every call, and when they do any linking they'll use the specified command instead of the built-in default. Easy-peasy, and CMake need not concern itself with such things at all.
(BTW, the option is parsed (-f) (use-ld) (=) (lld), there's no "fuse" option to gcc.)
Notes
When using Clang, lld can be replaced with whatever other linker command you want to use, like ld.exe, ld.gold, mingw32/bin/ld.exe, etc.
GCC isn't as flexible, its -fuse-ld only accepts one of three possible arguments: lld, bfd, or gold. It will invoke the first matching ld.foo executable it finds on the PATH. (Thanks to bviktor for pointing out GCC's limitations for alternate linker selection.)
CMake only gives you direct control over the compiler for each language. To call the linker, it goes through the configured compiler. This means that there is no universal way to set the linker in CMake, you must configure your compiler to use the linker you intend.
Such flags need to be set before CMake's compiler detection routines run because it will try to compile a test binary. The best way to do this is by creating a toolchain file. The best way to set these flags in the toolchain file is like so:
# e.g. to use lld with Clang
set(CMAKE_EXE_LINKER_FLAGS_INIT "-fuse-ld=lld")
set(CMAKE_MODULE_LINKER_FLAGS_INIT "-fuse-ld=lld")
set(CMAKE_SHARED_LINKER_FLAGS_INIT "-fuse-ld=lld")
These three variables control the (default) set of linker flags for executables, loadable modules, and shared libraries, respectively. There is no need to handle CMAKE_STATIC_LINKER_FLAGS_INIT (for static libraries) here because the archiver is invoked, rather than the linker.
You can then set the toolchain file when you first run CMake by setting -DCMAKE_TOOLCHAIN_FILE=/path/to/toolchain.cmake at the command line. As of CMake 3.21, you will be able to pass --toolchain /path/to/toolchain.cmake instead (which is entirely equivalent, but a little less typing).
Set the variable ${CMAKE_LINKER} either in CMakeCache.txt or after ccmake . under advanced options.
I have to use CMAKE_CXX_LINK_EXECUTABLE, CMAKE_C_LINK_EXECUTABLE variable:
SET(CMAKE_C_LINK_EXECUTABLE "c:\\MoSync\\bin\\pipe-tool.exe")
I had success with doing
add_link_options("-fuse-ld=lld")
It is a variation on the previous answers here. The difference is the CMake command I use to set the flag.
Adding it to CMAKE_CXX_FLAGS has the disadvantage of then also having to add -Wno-unused-command-line-argument as the flags get also added to compilation commands, not only to linking ones.
The disadvantage of CMAKE_SHARED_LINKER_FLAGS is that you have to add it multiple times, to _SHARED_, _EXE_, and maybe I forgot something.
Here is a CMake function which sets linker based on some predefined arbitrary rules (Clang -> lld-version or lld, GCC -> gold).
The important parts:
Search for lld-version which matches the Clang compiler version (ex. lld-13 if Clang 13.x.x is used), falls back to lld if not found
add_link_options("-fuse-ld=lld-${CLANG_VERSION_MAJOR}")
Use all system threads when linker is set to gold:
add_link_options("-fuse-ld=gold;LINKER:--threads,--thread-count=${HOST_PROC_COUNT}")
The example is a bit too long because of comments, logs and custom logic, but it is self-contained and could be useful staring point for beginners.
function(select_best_linker) #lld for Clang and GNU gold for GCC
if (UNIX AND NOT APPLE)
include(ProcessorCount)
ProcessorCount(HOST_PROC_COUNT)
if(${CMAKE_CXX_COMPILER_ID} MATCHES Clang)
# By default LLD uses all system threads.
# This could be tweaked for versions 11+ (--threads=1), but cannot be disabled for older versions
# add_link_options("-fuse-ld=lld-${CLANG_VERSION_MAJOR};LINKER:--threads=${HOST_PROC_COUNT}") #LLD>=11
# add_link_options("-fuse-ld=lld;LINKER:--threads")#LLD <= 10 this is the default state
string(REPLACE "." ";" VERSION_LIST ${CMAKE_CXX_COMPILER_VERSION})
list(GET VERSION_LIST 0 CLANG_VERSION_MAJOR) #extract major compiler version
find_program(LLD_PROGRAM_MATCH_VER lld-${CLANG_VERSION_MAJOR}) #search for lld-13 when clang 13.x.x is used
find_program(LLD_PROGRAM lld) #else find default lld
if (LLD_PROGRAM_MATCH_VER) #lld matching compiler version
message(STATUS "Set linker to LLD (multi-threaded): ${LLD_PROGRAM_MATCH_VER}")
add_link_options("-fuse-ld=lld-${CLANG_VERSION_MAJOR}")
elseif(LLD_PROGRAM) #default lld
message(STATUS "Set linker to LLD (multi-threaded): ${LLD_PROGRAM}")
add_link_options("-fuse-ld=lld")
endif(LLD_PROGRAM_MATCH_VER)
elseif(${CMAKE_CXX_COMPILER_ID} MATCHES GNU)
find_program(GNU_GOLD_PROGRAM gold)
if (GNU_GOLD_PROGRAM)
message(STATUS "Set linker to GNU gold: ${GNU_GOLD_PROGRAM}, using threads: ${HOST_PROC_COUNT}")
add_link_options("-fuse-ld=gold;LINKER:--threads,--thread-count=${HOST_PROC_COUNT}")
endif(GNU_GOLD_PROGRAM)
endif(${CMAKE_CXX_COMPILER_ID} MATCHES Clang)
endif(UNIX AND NOT APPLE)
endfunction(select_best_linker)
Tested on:
Ubuntu 20.04
CMake 3.16.3
GCC 9.4.0
Clang-12
Clang-13
GNU gold (GNU Binutils 2.37) 1.16
LLD 10.0.0 (compatible with GNU linkers)
Ubuntu LLD 13.0.1 (compatible with GNU linkers)
For completeness, another full-proof option is to just link /usr/bin/ld to ld.gold by running
sudo ln -sf /usr/bin/x86_64-linux-gnu-ld.gold /usr/bin/ld
as suggested here
There is another way to do it, gcc has a "-fuse-ld" option, you can set LINKER_FLAGS in CMakeLists.txt like these:
set(CMAKE_SHARED_LINKER_FLAGS "${CMAKE_SHARED_LINKER_FLAGS} -fuse-ld=lld")
set(CMAKE_EXE_LINKER_FLAGS "${CMAKE_EXE_LINKER_FLAGS} -fuse-ld=lld")
then the custom specified linker should be invoked.