Windows 10, CMake 3.19.1
Im trying to compile test project with XC8 compiler, CMake and custom toolchain (third party).
Link: Toolchain repository
Toolchains quick guide says to only add two strings at top of my CMakeLists.txt.
So ive got the next CMakeLists.txt:
project(Test)
# set up the Microchip cross toolchain
set(CMAKE_TOOLCHAIN_FILE ./external/cmake-microchip/toolchain.cmake)
# set the default MCU model
set(MICROCHIP_MCU PIC18F97J60)
add_executable(main main.c)
But occasionaly, every time CMake generation output starts with:
-- Building for: Visual Studio 16 2019
-- The C compiler identification is MSVC 19.28.29333.0
-- The CXX compiler identification is MSVC 19.28.29333.0
..... more
And i havent any Makefile in the output folder.
Also im try to run CMake with -G "Unix makefiles". And makefile been generated, with wrong output and any trace of custom toolchain use.
Output been:
-- The C compiler identification is GNU 9.2.0
-- The CXX compiler identification is GNU 9.2.0
-- Detecting C compiler ABI info
Every CMake generation try, im cleanup the output folder.
Why custom toolchain doesnt starts?
The variable CMAKE_TOOLCHAIN_FILE should be set before the first project() call:
cmake_minimum_required(VERSION <..>)
# set up the Microchip cross toolchain
set(CMAKE_TOOLCHAIN_FILE ./external/cmake-microchip/toolchain.cmake)
project(Test)
# set the default MCU model
set(MICROCHIP_MCU PIC18F97J60)
add_executable(main main.c)
When first project() call is processed, CMake automatically calls the script specified in CMAKE_TOOLCHAIN_FILE.
Note, that preferred way is to not hardcode path to the toolchain in the CMakeLists.txt but pass -DCMAKE_TOOLCHAIN_FILE=/path/to/toolchain option to the cmake.
Related
I'm using this C package for numerical integration in several implementations. So far, what I do is copy the associated folder (after downloading the cubature-master in Github) into the same directory of my scripts, include the package as
#include "cubature-master/cubature.h"
and add the corresponding flag when compiling my code. I'm doing all of this locally on my Mac arm64. As suggested in the comments, I compiled the package via CMake and I got these results:
Sebastians-Macbook-Pro:cubature-master surrutiaquir$ cd build Sebastians-Macbook-Pro:build surrutiaquir$ cmake ..
-- The C compiler identification is AppleClang 13.0.0.13000029
-- The CXX compiler identification is AppleClang 13.0.0.13000029
-- Check for working C compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc
-- Check for working C compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/cc
- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++
-- Check for working CXX compiler: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++
- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Configuring done
-- Generating done
-- Build files have been written to: /Users/surrutiaquir/Software/cubature-master/build Sebastians-Macbook-Pro:build surrutiaquir$ make Scanning dependencies of target cubature [ 33%] Building C object CMakeFiles/cubature.dir/hcubature.c.o [ 66%] Building C object CMakeFiles/cubature.dir/pcubature.c.o [100%] Linking C shared library libcubature.dylib ld: warning: ignoring file CMakeFiles/cubature.dir/pcubature.c.o, building for macOS-x86_64 but attempting to link with file built for unknown-arm64 ld: warning: ignoring file CMakeFiles/cubature.dir/hcubature.c.o, building for macOS-x86_64 but attempting to link with file built for unknown-arm64 [100%] Built target cubature Sebastians-Macbook-Pro:build surrutiaquir$ make install [100%] Built target cubature Install the project...
-- Install configuration: ""
-- Installing: /usr/local/lib/libcubature.dylib
-- Installing: /usr/local/include/cubature.h
I would like to have the package in a single location but I'm not skilled enough to reference that path during the compiling process. My goal is to create a Makefile to deal with all of this. Any guidance would be highly appreciated.
I am trying to get CMAKE to use a specific compiler when running. Specifically, I want it to use the locally installed GCC compiler. But when i try to set the CMAKE_C_COMPILER variable, it seems to fail.
set(CMAKE_C_COMPILER "gcc")
set(CMAKE_CXX_COMPILER "g++")
cmake_minimum_required(VERSION 3.10)
PROJECT(hello C)
add_executable(hello hello.c)
UPDATE USING TOOLCHAIN
I tried to make it work using the following toolchain file, but it still chooses Visual Studio build tools.
# Toolchain File
# The target of this operating systems is
SET(CMAKE_SYSTEM_NAME Windows)
# which compilers to use for C and C++
SET(CMAKE_C_COMPILER gcc)
SET(CMAKE_CXX_COMPILER g++)
# here is the target environment located
SET(CMAKE_FIND_ROOT_PATH C:/MyPrograms/MinGW/bin/ )
# adjust the default behaviour of the FIND_XXX() commands:
# search headers and libraries in the target environment, search
# programs in the host environment
set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
MORE UPDATES ON ISSUE
When i look at the cache file created when using the toolchain file, i find something interesting. It is trying to point to the correct compiler, but it is using the Visual Studio Generator still...
//Name of generator.
CMAKE_GENERATOR:INTERNAL=Visual Studio 15 2017
//Generator instance identifier.
CMAKE_GENERATOR_INSTANCE:INTERNAL=C:/Program Files (x86)/Microsoft Visual Studio/2017/BuildTools/
How do i deal with the generator here?
CMake is a tool that is intended for defining dependencies among the targets in your application. You define the dependencies and set the language requirements for your targets, and you ask CMake to generate files to help you build your targets. Having this in mind, please do not mess with the CMAKE_C(XX)_COMPILER variables directly in your CMakeLists.txt, but rather think of using toolchain files to define the specific compiler/linker properties. Using toolchain files, you can not only define different compiler/linker setups for your host but also do cross-compilation, in which the host and target devices are of different architecture.
EDIT. To be able to use the locally installed gcc compiler, you do not need to play with any of the (related) variables inside your CMakeLists.txt file. Instead, you should (re)define your PATH environment variable to include the corresponding (i.e., MinGW or Cygwin) binaries, and select an appropriate generator. Below is a minimal working example based on your code.
Assume that you have the following directory structure:
.
├── appveyor.yml
├── CMakeLists.txt
└── hello.c
with hello.c having the contents
#include <stdio.h>
int main(int argc, char *argv[]) {
printf("Hello world!\n");
return 0;
}
CMakeLists.txt having the contents
cmake_minimum_required(VERSION 3.10)
project(hello C)
add_executable(hello hello.c)
and finally, appveyor.yml having the following
image: Visual Studio 2013
environment:
matrix:
- generator: "Visual Studio 12 2013 Win64"
- generator: "MSYS Makefiles"
before_build:
- IF "%generator%"=="MSYS Makefiles" set PATH=C:\msys64\usr\bin;C:\mingw-w64\x86_64-8.1.0-posix-seh-rt_v6-rev0\bin;%PATH%
build_script:
- mkdir build
- cd build
- cmake -G "%generator%" ..
- cmake --build .
after_build:
- IF EXIST Debug cd Debug
- hello.exe
This example successfully builds on AppVeyor with both of the toolchains. The catch here is that when you go for MSYS Makefiles, or MinGW Makefiles for that matter, you should define your PATH variable to include the binaries to the compiler toolchain. In the above example, I simply use the default paths for AppVeyor's VMs. Another thing to note for appveyor.yml is that the Visual Studio generators use different (sub)directories for different CMAKE_BUILD_TYPEs. Hence, I first check the existence of the directory Debug, and if it exists, I change to the directory and run hello.exe.
I hope this answers your question.
I am trying to cross compile simple project on my PC to get working on RaspberryPi. I found some tutorials on web and made cmake file. Basic cmake file work on rpi side, but cross compile additional file have some problems. Makefiles are generated properly, but invoking make throws out that it can't find
wiringPi.h library, which ofc I am using. I have synchronized /lib and /usr from rpi to my pc.
Here is my cmake for cross compilation.
#info
SET(CMAKE_SYSTEM_NAME Linux)
SET(CMAKE_SYSTEM_VERSION 1)
# specify the cross compilers
SET(CMAKE_C_COMPILER
/home/voodoo16/raspberryPi/tools/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian/bin/arm-linux-gnueabihf-gcc)
SET(CMAKE_CXX_COMPILER
/home/voodoo16/raspberryPi/tools/arm-bcm2708/gcc-linaro-arm-linux-gnueabihf-raspbian/bin/arm-linux-gnueabihf-g++)
# where is the target environment
SET(CMAKE_FIND_ROOT_PATH /home/voodoo16/raspberryPi/fs)
# search for programs in the build host directories
SET(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
# for libraries and headers in the target directories
SET(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY ONLY)
SET(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE ONLY)
Of course I invoke cmake creation via:
cmake -DCMAKE_TOOLCHAIN_FILE=crossCompile.cmake .
Files exist in fs folder. Here is output of find:
voodoo16#tesla:[~/raspberryPi/fs]$ find -name *wiringPi*
./usr/local/include/wiringPiSPI.h
./usr/local/include/wiringPi.h
./usr/local/include/wiringPiI2C.h
./usr/local/lib/libwiringPi.so
./usr/local/lib/libwiringPi.so.2.32
./usr/local/lib/libwiringPiDev.so
./usr/local/lib/libwiringPiDev.so.2.32
./usr/lib/libwiringPi.so
./usr/lib/libwiringPiDev.so
I suppose that I'm missing some cmake command which allows to see libraries from rpi filesystem not via pc system using standard #include <lib.h>.
Best regards,
voodoo16.
You need to set CMake variable CMAKE_SYSROOT for hint compiler about cross compilation:
set(CMAKE_SYSROOT "/home/voodoo16/raspberryPi/fs")
CMake variables CMAKE_FIND_* affects only on CMake find_* commands, they don't directly hint the compiler. From the other side, CMAKE_SYSROOT variable hints for find_* commands too.
I'm having strange problems with my cmake cross-compiler projects.
My own libraries are found but not the (system) libraries from my toolchain.
Previously I was using KDevelop on debian squeeze machine.
now on my new machine with debian wheezy the configuring fails.
It does not find the system libraries like m or pthread.
On my old machine the following was working perfectly, but I do not remember that I did something special to make this work.
Here is one of my CMakeLists.txt files
cmake_minimum_required(VERSION 2.8)
SET(CMAKE_SYSTEM_NAME Linux)
SET(CMAKE_SYSTEM_VERSION 2.6.36.4)
SET(CMAKE_C_COMPILER arm-angstrom-linux-gnueabi-gcc)
SET(CMAKE_CXX_COMPILER arm-angstrom-linux-gnueabi-g++)
include_directories(../include
../../../sample/include)
project(testmain)
add_executable(testmain
some_c-source-file.c)
set(CMAKE_LIBRARY_PATH ../lib/arm-26/lib
../../../sample/lib/arm-26/lib)
find_library(LIBS_TEST NAMES akku)
find_library(LIBS_M NAMES m)
find_library(LIBS_PTHREAD NAMES pthread )
target_link_libraries(akkumain
${LIBS_TEST}
${LIBS_M}
${LIBS_PTHREAD})
set(CMAKE_C_FLAGS "-Wall -Werror")
set(CMAKE_C_FLAGS_DEBUG "-g3 -O2 -rdynamic")
set(CMAKE_C_FLAGS_RELEASE "-g0 -O0")
set(CMAKE_CXX_FLAGS "-Wall -Werror")
set(CMAKE_CXX_FLAGS_DEBUG "-g3 -O2 -rdynamic")
set(CMAKE_CXX_FLAGS_RELEASE "-g0 -O0")
This is the message displayed when trying to compile using KDevelop: (to repeat myself: this was working on my old machine)
/home/user/testmain/build> /usr/bin/cmake -DCMAKE_BUILD_TYPE=Debug /home/user/testmain/
-- The C compiler identification is GNU 4.3.3
-- The CXX compiler identification is GNU 4.3.3
-- Check for working C compiler: /usr/local/angstrom/arm/bin/arm-angstrom-linux-gnueabi-gcc
-- Check for working C compiler: /usr/local/angstrom/arm/bin/arm-angstrom-linux-gnueabi-gcc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working CXX compiler: /usr/local/angstrom/arm/bin/arm-angstrom-linux-gnueabi-g++
-- Check for working CXX compiler: /usr/local/angstrom/arm/bin/arm-angstrom-linux-gnueabi-g++ -- works
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
CMake Error: The following variables are used in this project, but they are set to NOTFOUND.
Please set them or make sure they are set and tested correctly in the CMake files:
LIBS_M
linked by target "akkumain" in directory /home/user/testmain
LIBS_PTHREAD
linked by target "akkumain" in directory /home/user/testmain
So LIBS_TEST is found. But not libm or libpthread.
I tried this with different projects: All of my libraries are found, but none of the "system" libraries.
I already tried different things like
set(CMAKE_FIND_LIBRARY_PREFIXES lib )
set(CMAKE_FIND_LIBRARY_SUFFIXES .a )
and some more things I do not remember.
The only thing what IS WORKING is when I specify the directory manually:
find_library(ASTLIBS_M NAMES m PATHS /usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/usr/lib)
After specifying this to my CMakeLists.txt the library is found and I can compile my project without any errors.
BUT: This is not what I want, because I have a LOT of projects and many libraries and I don't want to edit all my CMakeLists.txt... :(
Does anybody know what made my old machine find the system-libs without specifying anything special inside my IDE/CMake files?
Edit:
I just noticed for one of my executables that on Linker stage it throws some errors that it cannot find some symbols from glibc - seems there is something more wrong with my debian wheezy system. - I hope I can figure it out...
Edit:
Maybe I should give a short summary: My code compiles well, but all libraries from my toolchain are not found, but if I add the path to the libs of my toolchain manually it compiles but fails on linker stage.
Have you ever tried using a toolchain file? I also cross-compile to ARM and AVR a LOT and it works very well with no hassle (I also use KDevelop and it works beautifully along with CMake). The main point is specifying the path to your toolchain root filesystem through the CMAKE_FIND_ROOT_PATH variable. Try putting all this in a file, which I usually name after the architecture I'm cross-compiling to (in this case I called it arm-unknown-linux-gnueabi.cmake):
# the name of the target operating system
SET(CMAKE_SYSTEM_NAME Linux)
# which C and C++ compiler to use
SET(CMAKE_C_COMPILER arm-unknown-linux-gnueabi-gcc)
SET(CMAKE_CXX_COMPILER arm-unknown-linux-gnueabi-g++)
# here is the target environment located
SET(CMAKE_FIND_ROOT_PATH /home/claudio/TS-7400/rootfs)
# adjust the default behaviour of the FIND_XXX() commands:
# search headers and libraries in the target environment, search
# programs in the host environment
set(CMAKE_FIND_ROOT_PATH_MODE_PROGRAM NEVER)
set(CMAKE_FIND_ROOT_PATH_MODE_LIBRARY BOTH)
set(CMAKE_FIND_ROOT_PATH_MODE_INCLUDE BOTH)
Note the variables CMAKE_FIND_ROOT_PATH_MODE_xxx variables control where CMake will look for binaries, libraries and header files. I usually set PROGRAM to NEVER so it never uses binaries from your cross-architecture root filesystem, since they will not run on your host machine anyway. For libraries and header files BOTH means it will search first your specified ROOT_PATH and then if it doesn't find something it will go through your host machine system dirs.
That way, whenever you want to cross-compile a project all you have to do is to create a build directory (so it doesn't mix your sources with files created during build) and then run cmake from there specifying the toolchain file you want to use (I'm supposing your CMakeLists.txt is together with your toolchain file on the same dir your sources are located - project_sources_dir in my example):
cd project_sources_dir
mkdir build
cd build
cmake -DCMAKE_TOOLCHAIN_FILE=../arm-unknown-linux-gnueabi.cmake ..
The whole point of using a toolchain file is that, if you want to compile the exact same project for your host machine, you don't have to change a single line in your CMakeLists.txt. Just run cmake without specifying the toolchain file:
cd project_sources_dir
mkdir build
cd build
cmake ..
and your project is ready for compiling native for your host machine instead. If all that isn't enough, you can look for more details here on CMake Cross Compiling
There are certain default paths where CMake's find_library module searches. If your system libs on your old machine happen to be located in one such place, they will be found without any additional work needing to be done.
However, as your new machine's path to these libs seems to be "/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/usr/lib", you'll need to tell CMake about this.
One such way, is as you have shown (adding the path explicitly). But in this case, the path is probably specific to just that machine - so you'd be better to only set that path when you invoke CMake on that machine. You can add it to CMAKE_PREFIX_PATH for example:
cmake . -DCMAKE_PREFIX_PATH=/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/usr
(Note: the path in this case get "lib" appended when find_library is called).
Or if you only want to affect the find_library search paths, and not all find_xxx modules, set CMAKE_LIBRARY_PATH
cmake . -DCMAKE_LIBRARY_PATH=/usr/local/angstrom/arm/arm-angstrom-linux-gnueabi/usr/lib
I am trying to compile OpenCV on windows using CMAKE and MinGW on Windows. However, when I try to do that I am getting the following error:
The C compiler identification is GNU
The CXX compiler identification is GNU
Check for working C compiler: C:/MinGW/bin/gcc.exe
CMake Error: Generator: execution of make failed. Make command was: make "cmTryCompileExec\fast"
Check for working C compiler: C:/MinGW/bin/gcc.exe -- broken
CMake Error at C:/Program Files (x86)/CMake 2.8/share/cmake-2.8/Modules/CMakeTestCCompiler.cmake:52 (MESSAGE):
The C compiler "C:/MinGW/bin/gcc.exe" is not able to compile a simple test program.
Does anyone know what could be an issue?
Are you running CMAKE within the MinGW shell or within CMD.exe? The first suggestion I can give you is to use MinGW shell because several environment variables are better setup for the compiler in this way. Otherwise you may have to tweak a little your windows environment variables.
You may have also installed Cygwin (and installed gcc also in cygwin). In this case, if you use CMD.exe and that the bin directory of Cygwin is read first than the one of MinGW in the system PATH variable, you can get this kind of errors too.