Clion Cross Compile

 
  1. CLion For Embedded Development The CLion Blog
  2. Clion Cross Compile Arm
  3. Clion Arm
  4. Clion Help
  5. Clion Cross Compile Toolchain
  • OpenOCD + STM32CubeMX support for CLion. Contribute to elmot/clion-embedded-arm development by creating an account on GitHub.
  • I am trying to cross compile for an iMX8 development board. The board is running Boot2QT fine. I can successfully compile my sample project and install the application using QT Creator. I don't like QT Creator very much, and I am very used to IntelliJ IDEs, so I am attempting to use CLion.

On Windows, configuring CLion requires setting up the environment: Cygwin, MinGW, WSL, or Microsoft Visual C++. You can have several environments installed on your system and create separate CLion toolchains for each of them. As a determining part of a toolchain, the environment provides C and C++ compilers, the make utility, and the debugger (in case of using default tools).

ClionClion cmake cross compile

The first bug-fix update (build 211.7142.21) for the recently released CLion v2021.1 is now available on our website, via the patch-update, in the Toolbox App, or as a snap (for Ubuntu). DOWNLOAD CLION The highlights include: In code assistance and navigation: Fixed the regression that resulted in slow code completion (CPP-24744). To open a compilation database project, go to File Open, point CLion to the folder containing compilecommands.json or to the compilecommands.json file itself (then select Open as Project). Unable to cross-compile using CLion - GL/gl.h missing - Yes the packages are installed. This topic has been deleted. Only users with topic management privileges can see it. Mpdasa last edited by mpdasa. First off, I do have all the OpenGL dev packages installed and the headers are located at /usr/include. I am trying to cross compile for an.

For details on Remote Host toolchains, see Full Remote Mode.

MinGW

MinGW-w64 (64- and 32-bit)

  1. Download and run the MinGW-w64 installer. It provides both 64- and 32-bit options.

  2. In the MinGW-w64 installation wizard, make sure to select the required architecture. Note that the default suggested option is 32-bit.

  3. Once the installation is finished, open CLion and go to File Settings Build, Execution, Deployment Toolchains.

    Choose the MinGW toolchain that you want to configure or create a new one using the icon.

  4. CLion will attempt to detect the MinGW installation automatically. Check the detection result in the Environment field, and specify the path manually if required.

  5. Wait until the tools detection finishes.

  6. Select the Debugger: you can use either MinGW-w64 GDB or a custom GDB binary.

  7. Click Apply when all the tools are set correctly.

Although MinGW-w64 provides both 64- and 32-bit options, you can also install MinGW, the 32-bit-only version.

  1. In the MinGW installation wizard, select the following packages from the Basic Setup list: mingw-developer-tool, mingw32-base, mingw32-gcc-g++, mingw32-msys-base.

  2. Follow the steps 3-7 for MinGW-w64.

    • When configuring the toolchain, if CLion cannot detect compilers or make, double-check the installed packages in MinGW Installation Manager.

    • In the Debugger field, you can choose between the bundled GDB, MinGW GDB, or your custom GDB executable.

      The recommended option is bundled GDB, since it is guaranteed to include Python support required for CLion data renderers.

Cygwin

  1. Download the Cygwin installer, version 2.8 or later.

  2. Run the installer and select the following packages:

    • gcc-g++
    • make
    • gdb

    To select a package, type its name in the Search field and then click it in the list until a tick mark appears in the Bin? column:

  3. Once the installation is finished, open CLion and go to File Settings Build, Execution, Deployment Toolchains. Choose the toolchain that you want to configure.

  4. Select Cygwin from the Environment list. CLion will attempt to detect the Cygwin installation automatically. Check the detection result, and specify the path manually if required.

  5. Wait until the tools detection finishes, and press Apply.

Windows Subsystem for Linux

You can use WSL, Windows Subsystem for Linux, as your working environment in CLion on Windows 10 (starting the Fall Creators Update version 1709, build 16299.15).

WSL toolchain enables you to build projects using CMake and compilers from Linux and run/debug on WSL without leaving CLion running on your Windows machine.

Refer to our WSL guide for details on setting up WSL on your system and configuring WSL toolchains in CLion.

Microsoft Visual C++

Clion Cross Compile

  1. Install Visual Studio 2013, 2015, 2017, or 2019 on your system.

  2. In CLion, go to File Settings Build, Execution, Deployment Toolchains.

  3. Click and select Visual Studio from the list of toolchain templates.

  4. Check the Environment field. CLion will attempt to automatically detect the installed Visual Studio distribution. If the detection fails, set the path to Visual Studio manually.

  5. If required, specify the Architecture (x86, amd64, x86_arm, or another), Platform (store, uwp, onecore, or leave it blank), and Version. To build your project for the selected architecture, CLion will call the script to configure the environment with the specified parameters.

    If the version of your compiler toolset is earlier than the version of your Visual Studio installation, pass it in the Version field via the vcvars_ver flag, for example, -vcvars_ver=14.16.

  6. Wait until the tools detection is finished:

Clion Cross Compile

MSVC compiler

CLion supports the Microsoft Visual C++ compiler that ships with Visual Studio 2013, 2015, 2017, and 2019.

Note that msbuild is not supported: CLion runs CMake with the NMAKE generator instead.

For the case when your code includes MSVC extensions, CLion provides the support for:

  • __uuidof, __forceinline, __unaligned, and __alignof keywords;

  • pointer type attributes: __ptr32, __ptr64, __uptr, __sptr;

  • MSVC built-in data types: (unsigned) __int8, (unsigned) __int16, (unsigned) __int32, (unsigned) __int64, __wchar_t;

  • additional format specifiers, such as %I32 and %I64;

  • the clang 's -fms-extensions flag.

Clang-cl compiler

As an alternative compiler, you can use clang-cl- the MSVC-compatible compiler driver for Clang. CLion supports clang-cl version 8.0 and later.

  1. Install clang-cl from the LLVM site or along with the Visual Studio tools.

    When installed from the LLVM site, the clang-cl binary can be found at the standard location C:Program FilesLLVMbinclang-cl.exe for the 64-bit version or C:Program Files (x86)LLVMbinclang-cl.exe for the 32-bit version.

  2. In CLion, go to File Settings Build, Execution, Deployment Toolchains and select the Visual Studio toolchain that you want to configure, or create a new one.

  3. Point the C Compiler and C++ Compiler fields to clang-cl.exe. CLion will suggest the paths detected automatically.

Note that currently the -T clangcl options can't be picked up if the bundled CMake is in use along with the Visual Studio toolchain setup (CPP-18848 ).

LLDB-based MSVC debugger

The MSVC toolchain debugger is implemented on top of LLDB. It can work with native visualizers from the Visual Studio installation or from your project. To enable native visualizers support and set the desired diagnostics level, select Enable NatVis renderers for LLDB in Settings Build, Execution, Deployment Debugger Data Views C/C++:

Also, if you have custom native visualizers in your project, CLion will use them as well:

Clang compiler on Windows

With CMake 3.15, it has become possible to use the Clang compiler on Windows with the MinGW-w64/MinGW toolchain.

However, the LLVM Clang for Windows is built using Microsoft Visual Studio, and all the built-in macros and include search paths are set up for use with Visual Studio. So if you take Clang from the LLVM repository, it will not work correctly when configured with the MinGW toolchain. One of the possible workarounds is described below.

Set up the Clang compiler for MinGW

CLion For Embedded Development The CLion Blog

  1. Install MSYS2.

  2. Download the following packages with the pacman tool (use the pacman -S package_name command):

    • mingw-w64-x86_64-gcc

    • mingw-w64-x86_64-clang

    • mingw-w64-x86_64-lld

    • mingw-w64-x86_64-gdb

    • mingw-w64-x86_64-make

    • mingw-w64-x86_64-polly

    • mingw-w64-x86_64-compiler-rt

    This way, you will get the Clang compiler which is built with mingw-w64 and has paths and macros that correspond to this toolchain.

  3. Go to Settings / Preferences Build, Execution, Deployment Toolchains, create a MinGW toolchain, and set up the tools from MSYS.

    After specifying the Environment, check the automatically detected tools and make sure to switch to Clang in the C Compiler and C++ Compiler fields.

With this new toolchain configured, you can build the project and start using the Clang's advances tools, such as profile-guided optimization. Take a look at our detailed blogpost for instructions.

GDB on Windows

In the case of MinGW, CLion includes the bundled GDB (version 10.1). For Cygwin, you need to install the GDB package in the Cygwin Package Manager, as described in the Cygwin section of this guide.

You can also switch to a custom GDB binary. In this case, the supported GDB versions are 7.8.x-10.1.

Note that for GDB 8.0 and later, debugger output is redirected to CLion console by default. To enable opening an external console window for application input/output, go to Help Find Action or press Ctrl+Shift+A, search for Registry, and set the following key: cidr.debugger.gdb.workaround.windows.forceExternalConsole.

If cmake(1) is invoked with the command line parameter-DCMAKE_TOOLCHAIN_FILE=path/to/file, the file will be loaded early to setvalues for the compilers.The CMAKE_CROSSCOMPILING variable is set to true when CMake iscross-compiling.

Note that using the CMAKE_SOURCE_DIR or CMAKE_BINARY_DIRvariables inside a toolchain file is typically undesirable. The toolchainfile is used in contexts where these variables have different values when usedin different places (e.g. as part of a call to try_compile()). In mostcases, where there is a need to evaluate paths inside a toolchain file, the moreappropriate variable to use would be CMAKE_CURRENT_LIST_DIR, sinceit always has an unambiguous, predictable value.

A typical cross-compiling toolchain for Linux has content suchas:

The CMAKE_SYSTEM_NAME is the CMake-identifier of the target platformto build for.

The CMAKE_SYSTEM_PROCESSOR is the CMake-identifier of the target architectureto build for.

The CMAKE_SYSROOT is optional, and may be specified if a sysrootis available.

The CMAKE_STAGING_PREFIX is also optional. It may be used to specifya path on the host to install to. The CMAKE_INSTALL_PREFIX is alwaysthe runtime installation location, even when cross-compiling.

The _COMPILER'>CMAKE_<LANG>_COMPILER variables may be set to full paths, or tonames of compilers to search for in standard locations. For toolchains thatdo not support linking binaries without custom flags or scripts one may setthe CMAKE_TRY_COMPILE_TARGET_TYPE variable to STATIC_LIBRARYto tell CMake not to try to link executables during its checks.

CMake find_* commands will look in the sysroot, and the CMAKE_FIND_ROOT_PATHentries by default in all cases, as well as looking in the host system root prefix.Although this can be controlled on a case-by-case basis, when cross-compiling, itcan be useful to exclude looking in either the host or the target for particularartifacts. Generally, includes, libraries and packages should be found in thetarget system prefixes, whereas executables which must be run as part of the buildshould be found only on the host and not on the target. This is the purpose ofthe CMAKE_FIND_ROOT_PATH_MODE_* variables.

Cross compiling for compute nodes in the Cray Linux Environment can be donewithout needing a separate toolchain file. Specifying-DCMAKE_SYSTEM_NAME=CrayLinuxEnvironment on the CMake command line willensure that the appropriate build settings and search paths are configured.The platform will pull its configuration from the current environmentvariables and will configure a project to use the compiler wrappers from theCray Programming Environment's PrgEnv-* modules if present and loaded.

The default configuration of the Cray Programming Environment is to onlysupport static libraries. This can be overridden and shared librariesenabled by setting the CRAYPE_LINK_TYPE environment variable todynamic.

Running CMake without specifying CMAKE_SYSTEM_NAME willrun the configure step in host mode assuming a standard Linux environment.If not overridden, the PrgEnv-* compiler wrappers will end up getting used,which if targeting the either the login node or compute node, is likely not thedesired behavior. The exception to this would be if you are building directlyon a NID instead of cross-compiling from a login node. If trying to buildsoftware for a login node, you will need to either first unload thecurrently loaded PrgEnv-* module or explicitly tell CMake to use thesystem compilers in /usr/bin instead of the Cray wrappers. If insteadtargeting a compute node is desired, just specify theCMAKE_SYSTEM_NAME as mentioned above.

Some compilers such as Clang are inherently cross compilers.The _COMPILER_TARGET'>CMAKE_<LANG>_COMPILER_TARGET can be set to pass avalue to those supported compilers when compiling:

Similarly, some compilers do not ship their own supplementary utilitiessuch as linkers, but provide a way to specify the location of the externaltoolchain which will be used by the compiler driver. The_COMPILER_EXTERNAL_TOOLCHAIN'>CMAKE_<LANG>_COMPILER_EXTERNAL_TOOLCHAIN variable can be set in atoolchain file to pass the path to the compiler driver.

As the Clang compiler the QNX QCC compile is inherently a cross compiler.And the _COMPILER_TARGET'>CMAKE_<LANG>_COMPILER_TARGET can be set to pass avalue to those supported compilers when compiling:

Cross compiling for Windows CE requires the corresponding SDK beinginstalled on your system. These SDKs are usually installed underC:/ProgramFiles(x86)/WindowsCETools/SDKs.

A toolchain file to configure a Visual Studio generator forWindows CE may look like this:

The CMAKE_GENERATOR_PLATFORM tells the generator which SDK to use.Further CMAKE_SYSTEM_VERSION tells the generator what version ofWindows CE to use. Currently version 8.0 (Windows Embedded Compact 2013) issupported out of the box. Other versions may require one to setCMAKE_GENERATOR_TOOLSET to the correct value.

A toolchain file to configure a Visual Studio generator for aWindows 10 Universal Application may look like this:

A Windows 10 Universal Application targets both Windows Store andWindows Phone. Specify the CMAKE_SYSTEM_VERSION variableto be 10.0 to build with the latest available Windows 10 SDK.Specify a more specific version (e.g. 10.0.10240.0 for RTM)to build with the corresponding SDK.

A toolchain file to configure a Visual Studio generator forWindows Phone may look like this:

A toolchain file to configure a Visual Studio generator forWindows Store may look like this:

Clion Cross Compile Arm

A toolchain file may configure cross-compiling for Android by setting theCMAKE_SYSTEM_NAME variable to Android. Further configurationis specific to the Android development environment to be used.

For Visual Studio Generators, CMake expects NVIDIA Nsight TegraVisual Studio Edition or the Visual Studio tools for Android to be installed. See those sectionsfor further configuration details.

For Makefile Generators and the Ninja generator,CMake expects one of these environments:

CMake uses the following steps to select one of the environments:

  • If the CMAKE_ANDROID_NDK variable is set, the NDK at thespecified location will be used.

  • Else, if the CMAKE_ANDROID_STANDALONE_TOOLCHAIN variableis set, the Standalone Toolchain at the specified location will be used.

  • Else, if the CMAKE_SYSROOT variable is set to a directoryof the form <ndk>/platforms/android-<api>/arch-<arch>, the <ndk>part will be used as the value of CMAKE_ANDROID_NDK and theNDK will be used.

  • Else, if the CMAKE_SYSROOT variable is set to a directory of theform <standalone-toolchain>/sysroot, the <standalone-toolchain> partwill be used as the value of CMAKE_ANDROID_STANDALONE_TOOLCHAINand the Standalone Toolchain will be used.

  • Else, if a cmake variable ANDROID_NDK is set it will be usedas the value of CMAKE_ANDROID_NDK, and the NDK will be used.

  • Else, if a cmake variable ANDROID_STANDALONE_TOOLCHAIN is set, it will beused as the value of CMAKE_ANDROID_STANDALONE_TOOLCHAIN, and theStandalone Toolchain will be used.

  • Else, if an environment variable ANDROID_NDK_ROOT orANDROID_NDK is set, it will be used as the value ofCMAKE_ANDROID_NDK, and the NDK will be used.

  • Else, if an environment variable ANDROID_STANDALONE_TOOLCHAIN isset then it will be used as the value ofCMAKE_ANDROID_STANDALONE_TOOLCHAIN, and the StandaloneToolchain will be used.

  • Else, an error diagnostic will be issued that neither the NDK orStandalone Toolchain can be found.

New in version 3.20: If an Android NDK is selected, its version number is reportedin the CMAKE_ANDROID_NDK_VERSION variable.

A toolchain file may configure Makefile Generators,Ninja Generators, or Visual Studio Generators to targetAndroid for cross-compiling.

Configure use of an Android NDK with the following variables:

CMAKE_SYSTEM_NAME

Set to Android. Must be specified to enable cross compilingfor Android.

CMAKE_SYSTEM_VERSION

Set to the Android API level. If not specified, the value isdetermined as follows:

  • If the CMAKE_ANDROID_API variable is set, its valueis used as the API level.

  • If the CMAKE_SYSROOT variable is set, the API level isdetected from the NDK directory structure containing the sysroot.

  • Otherwise, the latest API level available in the NDK is used.

CMAKE_ANDROID_ARCH_ABI

Set to the Android ABI (architecture). If not specified, thisvariable will default to the first supported ABI in the list ofarmeabi, armeabi-v7a and arm64-v8a.The CMAKE_ANDROID_ARCH variable will be computedfrom CMAKE_ANDROID_ARCH_ABI automatically.Also see the CMAKE_ANDROID_ARM_MODE andCMAKE_ANDROID_ARM_NEON variables.

CMAKE_ANDROID_NDK

Set to the absolute path to the Android NDK root directory.If not specified, a default for this variable will be chosenas specified above.

CMAKE_ANDROID_NDK_DEPRECATED_HEADERS

Set to a true value to use the deprecated per-api-level headersinstead of the unified headers. If not specified, the default willbe false unless using a NDK that does not provide unified headers.

CMAKE_ANDROID_NDK_TOOLCHAIN_VERSION

On NDK r19 or above, this variable must be unset or set to clang.On NDK r18 or below, set this to the version of the NDK toolchain tobe selected as the compiler. If not specified, the default will bethe latest available GCC toolchain.

Clion Arm

CMAKE_ANDROID_STL_TYPE

Clion Help

Set to specify which C++ standard library to use. If not specified,a default will be selected as described in the variable documentation.

The following variables will be computed and provided automatically:

_ANDROID_TOOLCHAIN_PREFIX'>CMAKE_<LANG>_ANDROID_TOOLCHAIN_PREFIX

The absolute path prefix to the binutils in the NDK toolchain.

_ANDROID_TOOLCHAIN_SUFFIX'>CMAKE_<LANG>_ANDROID_TOOLCHAIN_SUFFIX

The host platform suffix of the binutils in the NDK toolchain.

For example, a toolchain file might contain:

Alternatively one may specify the values without a toolchain file:

CLion remote debugging for ARM platform using cross toolchain ...

A toolchain file may configure Makefile Generators or theNinja generator to target Android for cross-compilingusing a standalone toolchain.

Configure use of an Android standalone toolchain with the following variables:

CMAKE_SYSTEM_NAME

Set to Android. Must be specified to enable cross compilingfor Android.

CMAKE_ANDROID_STANDALONE_TOOLCHAIN

Set to the absolute path to the standalone toolchain root directory.A ${CMAKE_ANDROID_STANDALONE_TOOLCHAIN}/sysroot directorymust exist.If not specified, a default for this variable will be chosenas specified above.

CMAKE_ANDROID_ARM_MODE

When the standalone toolchain targets ARM, optionally set this to ONto target 32-bit ARM instead of 16-bit Thumb.See variable documentation for details.

CMAKE_ANDROID_ARM_NEON

When the standalone toolchain targets ARM v7, optionally set thisto ONto target ARM NEON devices. See variable documentation for details.

The following variables will be computed and provided automatically:

CMAKE_SYSTEM_VERSION

The Android API level detected from the standalone toolchain.

CMAKE_ANDROID_ARCH_ABI

The Android ABI detected from the standalone toolchain.

_ANDROID_TOOLCHAIN_PREFIX'>CMAKE_<LANG>_ANDROID_TOOLCHAIN_PREFIX

The absolute path prefix to the binutils in the standalone toolchain.

_ANDROID_TOOLCHAIN_SUFFIX'>CMAKE_<LANG>_ANDROID_TOOLCHAIN_SUFFIX

The host platform suffix of the binutils in the standalone toolchain.

For example, a toolchain file might contain:

Alternatively one may specify the values without a toolchain file:

A toolchain file to configure one of the Visual Studio Generatorsto build using NVIDIA Nsight Tegra targeting Android may look like this:

The CMAKE_GENERATOR_TOOLSET may be set to selectthe Nsight Tegra 'Toolchain Version' value.

See also target properties:

  • ANDROID_ANT_ADDITIONAL_OPTIONS

  • ANDROID_API_MIN

  • ANDROID_API

  • ANDROID_ARCH

  • ANDROID_ASSETS_DIRECTORIES

  • ANDROID_GUI

  • ANDROID_JAR_DEPENDENCIES

  • ANDROID_JAR_DIRECTORIES

  • ANDROID_JAVA_SOURCE_DIR

  • ANDROID_NATIVE_LIB_DEPENDENCIES

  • ANDROID_NATIVE_LIB_DIRECTORIES

  • ANDROID_PROCESS_MAX

  • ANDROID_PROGUARD_CONFIG_PATH

  • ANDROID_PROGUARD

  • ANDROID_SECURE_PROPS_PATH

  • ANDROID_SKIP_ANT_STEP

  • ANDROID_STL_TYPE

For cross-compiling to iOS, tvOS, or watchOS, the Xcodegenerator is recommended. The UnixMakefiles orNinja generators can also be used, but they require theproject to handle more areas like target CPU selection and code signing.

Any of the three systems can be targeted by setting theCMAKE_SYSTEM_NAME variable to a value from the table below.By default, the latest Device SDK is chosen. As for all Apple platforms,a different SDK (e.g. a simulator) can be selected by setting theCMAKE_OSX_SYSROOT variable, although this should rarely benecessary (see Switching Between Device and Simulator below).A list of available SDKs can be obtained by running xcodebuild-showsdks.

OS

CMAKE_SYSTEM_NAME

Device SDK (default)

Simulator SDK

iOS

iOS

iphoneos

iphonesimulator

tvOS

tvOS

appletvos

appletvsimulator

watchOS

watchOS

watchos

watchsimulator

For example, to create a CMake configuration for iOS, the followingcommand is sufficient:

Variable CMAKE_OSX_ARCHITECTURES can be used to set architecturesfor both device and simulator. Variable CMAKE_OSX_DEPLOYMENT_TARGETcan be used to set an iOS/tvOS/watchOS deployment target.

Next configuration will install fat 5 architectures iOS libraryand add the -miphoneos-version-min=9.3/-mios-simulator-version-min=9.3flags to the compiler:

Example:

Install:

Check library:

Some build artifacts for the embedded Apple platforms require mandatorycode signing. If the Xcode generator is being used andcode signing is required or desired, the development team ID can bespecified via the CMAKE_XCODE_ATTRIBUTE_DEVELOPMENT_TEAM CMake variable.This team ID will then be included in the generated Xcode project.By default, CMake avoids the need for code signing during the internalconfiguration phase (i.e compiler ID and feature detection).

When configuring for any of the embedded platforms, one can target eitherreal devices or the simulator. Both have their own separate SDK, but CMakeonly supports specifying a single SDK for the configuration phase. Thismeans the developer must select one or the other at configuration time.When using the Xcode generator, this is less of a limitationbecause Xcode still allows you to build for either a device or a simulator,even though configuration was only performed for one of the two. Fromwithin the Xcode IDE, builds are performed for the selected 'destination'platform. When building from the command line, the desired sdk can bespecified directly by passing a -sdk option to the underlying buildtool (xcodebuild). For example:

Please note that checks made during configuration were performed againstthe configure-time SDK and might not hold true for other SDKs. Commandslike find_package(), find_library(), etc. store and usedetails only for the configured SDK/platform, so they can be problematicif wanting to switch between device and simulator builds. You can followthe next rules to make device + simulator configuration work:

Clion Cross Compile Toolchain

  • Use explicit -l linker flag,e.g. target_link_libraries(fooPUBLIC'-lz')

  • Use explicit -framework linker flag,e.g. target_link_libraries(fooPUBLIC'-frameworkCoreFoundation')

  • Use find_package() only for libraries installed withCMAKE_IOS_INSTALL_COMBINED feature