Integrate CLion and Android NDK - gcc

Recently I've found CLion. I'm trying to configure it to work with Android ndk:
I want it to use the ndk sources and headers.
I want it to use the gcc and g++ compiler in the ndk.
I want it to use my makefile and not cmake.
Couldn't achieve those three targets, hope you can help me :).
By the way I'm using android ndk r10e if it matters.

You can set up CLion to build for android by doing the following:
Install the NDK Standalone Toolchain (https://developer.android.com/ndk/guides/standalone_toolchain.html)
In CLion Preference/Settings under Build, Execution, Deployment > Toolchains, add a new toolchain for ARM, set the C compiler path to $NDK_TOOLCHAIN_PATH/arm/bin/arm-linux-androideabi-clang, set the C++ compiler path to $NDK_TOOLCHAIN_PATH/arm/bin/arm-linux-androideabi-clang++, and if you're on Windows, set the MinGW path. The toolchain tab is a fairly new feature to Clion so make sure you have a recent version of Clion.
Repeat step 2 for any other architectures you want to support
Go to Build, Execution, Deployment > CMake. Add a new profile for ARM. Set the toolchain to the ARM toolchain and set the CMake options to
-DCMAKE_CXX_FLAGS="-fPIE -fPIC -lstdc++"
-DCMAKE_AR="$NDK_TOOLCHAIN_PATH/arm/bin/arm-linux-androideabi-ar"
-DCMAKE_RANLIB="$NDK_TOOLCHAIN_PATH/arm/bin/arm-linux-androideabi-ranlib"
If you're using a Mac you will need these too in order to tell CMake to not use the isysroot option
-DCMAKE_OSX_SYSROOT="/"
-DCMAKE_OSX_DEPLOYMENT_TARGET=""
Repeat step 4 for any other architectures you want to support
When building, set the profile to your desired architecture (instead of Debug/Release).
Ideally, you could specify the entire toolchain (ar, ranlib, etc.) through CLion instead of using CMake options, but I haven't found a way to do so yet.

CLion can work only with CMake-projects. Others are not possible at this stage.
However, you can use Android Studio. It include C++ support based on CLion and works nicely with ndk for sure.

Related

Cross compilation with Buildroot

Advice on working with Buildroot cross compilation would be helpful.
I am currently using customer specific buildroot and trying to cross compile our applications using the provided toolchain. The toolchain provided by customer is in dir [...]/opt/gcc-linaro-7.5.0-2019.12-x86_64_arm-linux-gnueabihf/bin. The toolchain from buildroot is in buildroot/output/host/usr/bin.
Previously I have worked with Yocto Project and in yocto before using cross compilation we need to install the toolchain/sdk which is generated by bitbake -c populate_sdk <image recipe> and then each time we wish to use the toolchain we need to source the environment script. Do we have similar things in buildroot? Do we need to source any environment script? And also do I need to modify anything in menuconfig? Currently the toolchain set in menuconfig is "Linaro ARM 2018.05".
Can anyone please let me know how to continue with Buildroot? My end goal is to cross-compile and generate binaries using this toolchain.
Your help will be much appreciated.
Thanks in advance.
My understanding is that you want to use an external toolchain for building BSP.
In the buildroot menuconfig navigate to Toolchain and use below settings -
Toolchain type - External Toolchain
Toolchain - Custom toolchain
Toolchain origin - Pre-installed Toolchain
Toolchain Path - here you can choose the path [...]/opt/gcc-linaro-7.5.0-2019.12-x86_64_arm-linux-gnueabihf/bin
and make necessary settings for remaining toolchain settings and build.
snapshot

CMake and custom sdk (yocto+arm) for building target applications

I have received an SDK that is used to build c++/c applications for an embedded linux device. This is all new to me so some of my terminology may be wrong.
I followed their instructions and the SDK installs on my linux (ubuntu) system in /opt/. The compiler they are using appears to be arm-poky-linux-gnueabi-gcc. Part of their SDK sets some environment variables, like $CC and CPP for compiling C/C++. The environment variables run something like arm-poky-linux-gnueabi-gcc -march=armv7-a (and a bunch of other flags).
My question is: how can I utilize this using cmakelists/cmake? I currently have an entire library and application that is built around cmake.
The SDK should come with a toolchain file for cmake (for example named toolchain.cmake).
When you first call your cmake, you force it to use the SDK like this:
cmake -DCMAKE_TOOLCHAIN_FILE=/opt/???/toolchain.cmake.

Building a project with CMake, Ninja and Clang++ without MSVC

I'm currently working on a C++ project that build successfully on Linux using CMake, Make & GCC, and also on Windows using CMake & VS2015.
For some reason, i'd like to build it using the same toolchain everywhere, so i planned to use CMake, Clang & Ninja.
I started to try to build it on Windows, but i did not find any documentation to build using libc++ and without anything from the MSVC toolchain.
Am I forced to install MSVC build tools in order to build with CMake & Clang ?
Use a MinGW-w64 of GCC on Windows (e.g. the one from http://winlibs.com, or any other one listed at http://mingw-w64.org/).
If you combine this with the MSYS2 shell (http://www.msys2.org/), you can build a lot using the same tools as on Linux (autoconf, CMake, meson, ...).

Cross compiling for arm using crystax NDK

The android ndk supplied by google is unable to compile call to c++11 functions such as std::to_string() and std::stoul etc. {I had tried it in r10b one from the official site}. So the suggestion in SO was to try crystax NDK. I have downloaded and placed the root folder next to the google's NDK. All I changed in my root CMakeLists.txt file was:
from:
set(PLATFORM_PREFIX "/some-path/android-ndk-r10b/platforms/android-19/arch-arm")
set(PLATFORM_FLAGS "-fPIC -Wno-psabi --sysroot=${PLATFORM_PREFIX}")
set(CMAKE_CXX_FLAGS "${PLATFORM_FLAGS} -march=armv7-a -mfloat-abi=softfp -mfpu=neon" CACHE STRING "")
To:
set(PLATFORM_PREFIX "/some-path/android-ndk-r8-crystax-1/platforms/android-14/arch-arm")
set(PLATFORM_FLAGS "-fPIC -Wno-psabi --sysroot=${PLATFORM_PREFIX}")
set(CMAKE_CXX_FLAGS "${PLATFORM_FLAGS} -march=armv7-a -mfloat-abi=softfp -mfpu=neon" CACHE STRING "")
and cmake command-line from:
cmake .. -DCMAKE_CXX_COMPILER=/some-path/android-ndk-r10b/toolchains/arm-linux-androideabi-4.8/prebuilt/linux-x86_64/bin/arm-linux-androideabi-g++ -DCMAKE_C_COMPILER=/some-path/android-ndk-r10b/toolchains/arm-linux-androideabi-4.8/prebuilt/linux-x86_64/bin/arm-linux-androideabi-gcc -DANDROID_BUILD=ON -DANDROID_NDK_ROOT=/some-path/android-ndk-r10b
To:
cmake .. -DCMAKE_CXX_COMPILER=/some-path/android-ndk-r8-crystax-1/toolchains/arm-linux-androideabi-4.7/prebuilt/linux-x86_64/bin/arm-linux-androideabi-g++ -DCMAKE_C_COMPILER=/some-path/android-ndk-r8-crystax-1/toolchains/arm-linux-androideabi-4.7/prebuilt/linux-x86_64/bin/arm-linux-androideabi-gcc -DANDROID_BUILD=ON -DANDROID_NDK_ROOT=/some-path/android-ndk-r8-crystax-1
ie., changed from normal ndk to crystax-ndk. The program was compiling fine previously till it tried to compile a file with call to std::to_string() etc. But after the change Cmake gives an error that it is unable to compile a simple test program because:
/some-path/android-ndk-r8-crystax-1/toolchains/arm-linux-androideabi-4.7/prebuilt/linux-x86_64/bin/../lib/gcc/arm-linux-androideabi/4.7/../../../../arm-linux-androideabi/bin/ld:
error: cannot find -lcrystax
I can see libcrystax.a and .so in directorie:
/some-path/android-ndk-r8-crystax-1/sources/crystax/libs/armeabi-v7a
I tried adding link_directories("path-to-above") right at the beginning of the CMakeLists.txt file too, but that didn't solve it either.
It should find it there (after i supply the --sysroot etc above) just like the normal ndk. So how should this be solved ? Any other cmake variable to be set or something ?
I don't know how your cmake-based build system works, but actually if you properly add path /some-path/android-ndk-r8-crystax-1/sources/crystax/libs/armeabi-v7a to linker search paths, it should find libcrystax and link with it successfully.
Please note that NDK have several parts separated each from other - i.e. sysroot, libcrystax, C++ library - all are separated. It is done to work with NDK build system which offer some flexibility choosing C++ standard library implementation, and NDK build system know where to find all of them. In your case this approach is not so good so I suggest you first make standalone toolchain, which contains all things assembled together. In other words, it would be classic cross-compile toolchain which contains sysroot, libcrystax and GNU C++ standard library in places known to compiler/linker without passing of any additional options.
To create such toolchain, cd to NDK root directory and run the following command:
./build/tools/make-standalone-toolchain.sh --system=linux-x86_64 --toolchain=arm-linux-androideabi-4.7 --platform=android-14 --install-dir=$HOME/arm-linux-androideabi
Then use $HOME/arm-linux-androideabi as full standalone toolchain for your cmake-based build system.
Please note, however, that application built with CrystaX NDK r8 will not run on newest Android 5.0 due to changes in Bionic (libc). Previous Android versions (<=4.4) are all fine. We fixed that issue (and many others) in upcoming r10 release which is on final testing stage. In the meantime you could adopt your project to our r8 release and quickly switch to r10 when it done - the same approach will work with r10 as well as with r8.

Getting started with openMP. install on windows

I want to write parallel program in C++ using OpenMP, so I am getting started with OpenMP.
On the other words I am a beginner and I need good OpenMP guide telling how to install it.
Does someone know how to install OpenMP on Windows, then compile and run the program?
OpenMP is not something that you install. It comes with your compiler. You just need a decent compiler that supports OpenMP and you need to know how to enable OpenMP support since it is usually disabled by default.
The standard compiler for Windows comes from Microsoft and it is the Microsoft Visual C/C++ compiler from Visual Studio. Unfortunately its OpenMP support is a bit outdated - even the latest and greatest Visual Studio only supports OpenMP 2.0 (an outdated standard version from 2002). See here for more information on how to use OpenMP in Visual Studio. There are other compilers available as well - both Intel C/C++ Compiler (commercial license required) and GCC (freely available) support newer OpenMP versions and other compilers are available too.
You can start learning OpenMP by visiting the OpenMP web site here. Also there is a great tutorial on OpenMP from Lawrence Livermore National Laboratory available here.
2020 Update: Microsoft now ships Clang for Windows with Visual Studio. Although it is a bit convoluted, one can (ab)use the Clang-cl toolset to produce working 32-bit OpenMP programs. A number of steps are necessary:
If not already installed, add Clang and Clang-cl using the Visual Studio 2019 Installer.
Set the project's platform toolset (project Properties -> General -> Platform Toolset) to "LLVM (clang-cl)".
Enable Clang OpenMP support by adding -Xclang -fopenmp to the compiler options in project Properties -> C/C++ -> All Options -> Additional Options.Important: make sure that OpenMP support is disabled before switching the platform toolset (this is the default for new C++ projects). It seems that VS remembers the setting and still passes /openmp even though the language configuration for Clang has no option for OpenMP. If clang-cl.exe throws error MSB8055 (unsupported /openmp option) during build, set the platform toolset back to "Visual Studio 2019 (vXXX)" and disable the OpenMP support in Properties -> C/C++ -> Language -> Open MP Support, then switch the platform toolset again to "LLVM (Clang-cl)".
Add libomp.lib to the additional libraries in project Properties -> Linker -> Input -> Additional Dependencies.
Add the path to libomp.lib to the linker search path by adding a new entry with value $(LLVMInstallDir)\lib in project Properties -> Linker -> General -> Additional Library Directories.
Add a post-build action that copies LLVM's libomp.dll to the project output directory (without this step, running the executable will fail unless libomp.dll is in the DLL search path). In project Properties -> Build Events -> Post-Build Event -> Command Line:
xcopy /y "$(LLVMInstallDir)\bin\libomp.dll" "$(SolutionDir)$(Configuration)"
Build and run the project.
Note: this is very much likely still unsupported by Microsoft and it only works for x86 projects since the LLVM libraries shipped with VS are 32-bit only.
So here is what I did to finally get OpenMP working on my Windows 10 PC:
Get MinGW - Download and grab what you need to get the basic gcc compiler and the g++ pakage (its really easy to do). You can always run g++ -v to make sure it is up and running
Run mingw-get upgrade --recursive "gcc<4.7.*" "gcc-g++<4.7.*" This is the "Fun" part. Because at this time there was no libgomp library supported in their 4.9.* version my gcc wasn't able to recognize <omp.h> the last support version was 4.7.2 so with this I finally was able to run my openMP
To compile run g++ -fopenmp myOpenMPFile.cpp -o myOpenMP and it will all work from there
gcc -fopenmp myOpenMPFile.cpp -o myOpenMP will also work for C code
I would like to share what I did to get OpenMP working on my Windows 10 PC (things have got even simpler in 2019)
I installed MinGW distribution from here with GCC 8.2.0 compiler. The maintainer of the distribution has already added winpthreads and OpenMP support to GCC.
I compiled my code with -fopenmp flag as follows: g++ -fopenmp main.cpp -o exec
Note: the MinGW distribution provides support for many useful libraries (such as Boost 1.69.0) and other utilities. I found it to be very useful.

Resources