I am following this tutorial to install OpenCV using CMake for unity. I am stuck on step 6. I have specified the source folder for the source code field in CMake and made a new folder for the target. I have tested all three generator options which are Visual Studio 15 2017, Visual Studio 15 2017 win x64, Visual Studio 15 2017 ARM,
The problem is that I am unable to configure it. It says the following:
The following is the CMakeOutput.log file contents:-
The system is: Windows - 6.1.7601 - AMD64
The following is the CMakeCache.txt file contents:-
> # This is the CMakeCache file.
> # For build in directory: c:/Users/bhism/Downloads/Install
> # It was generated by CMake: D:/software/CMake/cmake-3.9.0-rc5-win64-x64/bin/cmake.exe
> # You can edit this file to change values found and used by cmake.
> # If you do not want to change any of the values, simply exit the editor.
> # If you do want to change a value, simply edit, save, and exit the editor.
> # The syntax for the file is as follows:
> # KEY:TYPE=VALUE
> # KEY is the name of a variable in the cache.
> # TYPE is a hint to GUIs for the type of VALUE, DO NOT EDIT TYPE!.
> # VALUE is the current value for the KEY.
>
> ########################
> # EXTERNAL cache entries
> ########################
>
> //Configs CMAKE_CONFIGURATION_TYPES:STRING=Debug;Release
>
> //Installation Directory
> CMAKE_INSTALL_PREFIX:PATH=C:/Users/bhism/Downloads/Install/install
>
> //Value Computed by CMake CMAKE_PROJECT_NAME:STATIC=OpenCV
>
> //Value Computed by CMake
> OpenCV_BINARY_DIR:STATIC=C:/Users/bhism/Downloads/Install
>
> //Value Computed by CMake
> OpenCV_SOURCE_DIR:STATIC=C:/Users/bhism/Downloads/opencv/sources
>
>
> ########################
> # INTERNAL cache entries
> ########################
>
> //This is the directory where this CMakeCache.txt was created
> CMAKE_CACHEFILE_DIR:INTERNAL=c:/Users/bhism/Downloads/Install //Major
> version of cmake used to create the current loaded cache
> CMAKE_CACHE_MAJOR_VERSION:INTERNAL=3 //Minor version of cmake used to
> create the current loaded cache CMAKE_CACHE_MINOR_VERSION:INTERNAL=9
> //Patch version of cmake used to create the current loaded cache
> CMAKE_CACHE_PATCH_VERSION:INTERNAL=0 //Path to CMake executable.
> CMAKE_COMMAND:INTERNAL=D:/software/CMake/cmake-3.9.0-rc5-win64-x64/bin/cmake.exe
> //Path to cpack program executable.
> CMAKE_CPACK_COMMAND:INTERNAL=D:/software/CMake/cmake-3.9.0-rc5-win64-x64/bin/cpack.exe
> //Path to ctest program executable.
> CMAKE_CTEST_COMMAND:INTERNAL=D:/software/CMake/cmake-3.9.0-rc5-win64-x64/bin/ctest.exe
> //Name of external makefile project generator.
> CMAKE_EXTRA_GENERATOR:INTERNAL= //Name of generator.
> CMAKE_GENERATOR:INTERNAL=Visual Studio 15 2017 ARM //Name of generator
> platform. CMAKE_GENERATOR_PLATFORM:INTERNAL= //Name of generator
> toolset. CMAKE_GENERATOR_TOOLSET:INTERNAL= //Source directory with the
> top level CMakeLists.txt file for this // project
> CMAKE_HOME_DIRECTORY:INTERNAL=C:/Users/bhism/Downloads/opencv/sources
> //number of local generators CMAKE_NUMBER_OF_MAKEFILES:INTERNAL=1
> //Platform information initialized
> CMAKE_PLATFORM_INFO_INITIALIZED:INTERNAL=1 //Path to CMake
> installation.
> CMAKE_ROOT:INTERNAL=D:/software/CMake/cmake-3.9.0-rc5-win64-x64/share/cmake-3.9
The actual error message:-
CMake Deprecation Warning at CMakeLists.txt:72 (cmake_policy):
The OLD behavior for policy CMP0020 will be removed from a future version
of CMake.
The cmake-policies(7) manual explains that the OLD behaviors of all
policies are deprecated and that a policy should be set to OLD only under
specific short-term circumstances. Projects should be ported to the NEW
behavior and not rely on setting a policy to OLD.
CMake Deprecation Warning at CMakeLists.txt:76 (cmake_policy):
The OLD behavior for policy CMP0022 will be removed from a future version
of CMake.
The cmake-policies(7) manual explains that the OLD behaviors of all
policies are deprecated and that a policy should be set to OLD only under
specific short-term circumstances. Projects should be ported to the NEW
behavior and not rely on setting a policy to OLD.
CMake Deprecation Warning at CMakeLists.txt:81 (cmake_policy):
The OLD behavior for policy CMP0026 will be removed from a future version
of CMake.
The cmake-policies(7) manual explains that the OLD behaviors of all
policies are deprecated and that a policy should be set to OLD only under
specific short-term circumstances. Projects should be ported to the NEW
behavior and not rely on setting a policy to OLD.
CMake Error at CMakeLists.txt:98 (project):
Failed to run MSBuild command:
MSBuild.exe
to get the value of VCTargetsPath:
Configuring incomplete, errors occurred!
See also "C:/Users/bhism/Downloads/Install/CMakeFiles/CMakeOutput.log".
I got tired of searching for the solution to this error yesterday. So, decided to started afresh for the day. Uninstalled all components. Downloaded all components again. Tried again. Within the third or fourth tweak, I worked like there wasn't any problem at at. This problem is solved now thanks
Related
I'm converting an old OCX project to QMake (as it's getting the "new" standard in my company).
In my Button.pro file, I add the MIDL compiler by the means of
idl_c.output = $${DESTDIR}/${QMAKE_FILE_BASE}.tlb
idl_c.input = IDL
idl_c.commands = $${QMAKE_IDL} ${QMAKE_FILE_IN} $${IDLFLAGS} \
/tlb ${QMAKE_FILE_OUT}
idl_c.variable_out = GENERATED_FILES
idl_c.CONFIG += target_predeps
idl_c.name = MIDL
QMAKE_EXTRA_COMPILERS += idl_c
IDL += $$PWD/Button.odl
The .pro file also mentions that I have a RC file
RC_FILE += $$PWD/Button.rc
This RC file contains a TYPELIB for this tlb file, meaning that it has to be available before rc.exe runs
1 TYPELIB "Button.tlb"
I then generate a makefile through QMake and build my project using nmake. Everything runs fine: the console shows no error and the output OCX is generated (and works). I can clearly see that MIDL is executed first, the RC, then the rest.
If I try to build using jom, the order is not satisfied anymore. jom seems to try to execute MIDL and RC in parallel: Button.tlb is then not yet existing at the time RC.exe needs it and the build fails.
Is there a way to force jom to wait for midl to be done before starting rc?
I'm using QT 5.3.1 under MSVC2013.
QMake is nothing more than a makefile generator. And your issue is due to make (or jom) parallel job execution. To fix this you only have to induce a single dependency (w/o any recipe) in a Makefile between res/obj and tlb files. This could be done with:
dep_restlb.target = $(RES_FILE)
dep_restlb.depends = $${DESTDIR}/Button.tlb # QMAKE_FILE_BASE is not available here
QMAKE_EXTRA_TARGETS += dep_restlb
I am trying to find the boost libraries (cmake) inside the Yocto SDK with extended environment on krogoth.
The default cmake Find_
find_package(Boost REQUIRED)
The standard error message
Unable to find the requested Boost libraries.
Unable to find the Boost header files. Please set BOOST_ROOT to the root
directory containing Boost or BOOST_INCLUDEDIR to the directory containing
Boost's headers.
Call Stack (most recent call first):
CMakeLists.txt:3 (find_package)
The following is a snippet from my conf/local.conf
IMAGE_INSTALL_append = " boost-dev"
IMAGE_INSTALL_append = " boost"
IMAGE_INSTALL_append = " kernel-devsrc"
MACHINE_ESSENTIAL_EXTRA_RRECOMMENDS += "kernel-module-hello"
KERNEL_MODULE_AUTO_lOAD += "hello-md"
LCHAIN_HOST_TASK_append = "${SDK_EXTRA_TOOLS}"
SDK_EXTRA_TOOLS = " nativesdk-cmake
I am using the native cmake
auke#xenialxerus:~/workspace/beaglebone-dev/build$ which cmake
/home/auke/workspace/beaglebone-dev/poky-sdk/tmp/sysroots/x86_64-linux/usr/bin/
since I:
source environment-setup-cortexa8hf-neon-poky-linux-gnueabi
looking for the usual headers in:
find ./tmp/sysroots/beaglebone/usr/include/boost/
..
/tmp/sysroots/beaglebone/usr/include/boost/vmd/list/to_seq.hpp
./tmp/sysroots/beaglebone/usr/include/boost/vmd/list/to_tuple.hpp
./tmp/sysroots/beaglebone/usr/include/boost/vmd/to_list.hpp
./tmp/sysroots/beaglebone/usr/include/boost/vmd/empty.hpp
./tmp/sysroots/beaglebone/usr/include/boost/vmd/is_list.hpp
./tmp/sysroots/beaglebone/usr/include/boost/vmd/size.hpp
./tmp/sysroots/beaglebone/usr/include/boost/vmd/get_type.hpp
./tmp/sysroots/beaglebone/usr/include/boost/vmd/assert_is_identifier.hpp
./tmp/sysroots/beaglebone/usr/include/boost/vmd/is_number.hpp
..
just like the binaries:
./tmp/sysroots/beaglebone/usr/lib/libboost_system-mt.a
./tmp/sysroots/beaglebone/usr/lib/libboost_iostreams.so.1.60.0
./tmp/sysroots/beaglebone/usr/lib/libboost_serialization-mt.a
./tmp/sysroots/beaglebone/usr/lib/libboost_date_time-mt.a
./tmp/sysroots/beaglebone/usr/lib/libboost_date_time.a
./tmp/sysroots/beaglebone/usr/lib/libboost_thread.so
./tmp/sysroots/beaglebone/usr/lib/libboost_signals-mt.a
./tmp/sysroots/beaglebone/usr/lib/libboost_date_time-mt.so
./tmp/sysroots/beaglebone/usr/lib/libboost_graph-mt.a
./tmp/sysroots/beaglebone/usr/lib/libboost_iostreams.so
./tmp/sysroots/beaglebone/usr/lib/libboost_regex.so
./tmp/sysroots/beaglebone/usr/lib/libboost_wserialization.so.1
Is there something that i might have overlooked?
regards Auke
You should use
bitbake -c populate_sdk <image_name> to generate the SDK based on your image;
As an alternative to locating and downloading a toolchain installer,
you can build the toolchain installer one of two ways if you have a
Build Directory:
*Use bitbake meta-toolchain. This method requires you to still install
the target sysroot by installing and extracting it separately. For
information on how to install the sysroot, see the "Extracting the
Root Filesystem" section.
*Use bitbake -c populate_sdk. This method has significant
advantages over the previous method because it results in a toolchain
installer that contains the sysroot that matches your target root
filesystem.
Also, using the variable TOOLCHAIN_HOST_TASK to add more packages.
http://www.yoctoproject.org/docs/1.8/ref-manual/ref-manual.html
This variable lists packages the OpenEmbedded build system uses when
building an SDK, which contains a cross-development environment. The
packages specified by this variable are part of the toolchain set that
runs on the SDKMACHINE, and each package should usually have the
prefix "nativesdk-". When building an SDK using bitbake -c
populate_sdk , a default list of packages is set in this
variable, but you can add additional packages to the list.
e.g.
TOOLCHAIN_HOST_TASK += “nativesdk-libqt5core-dev”
I have the problem including OpenSSL plugin in my corona project.
On this line
local openssl = require "plugin.openssl"
project crashes with error:
> module 'plugin_openssl' not found:resource (plugin_openssl.lu) does
> not exist in archive no field package.preload['plugin_openssl'] no
> file '/Users/Apple/Library/Application
> Support/Corona/Simulator/Plugins/plugin_openssl.lua' no file
> '/Users/Apple/Library/Application
> Support/luaglider2/dev/ProjectBuilds/___________(Builds)/___________(default)/___________/plugin_openssl.lua' no file '/Applications/CoronaSDK/Corona
> Simulator.app/Contents/Resources/plugin_openssl.lua' no file
> '/Users/Apple/Library/Application
> Support/Corona/Simulator/Plugins/plugin_openssl.dylib' no file
> './plugin_openssl.dylib' no file '/Applications/CoronaSDK/Corona
> Simulator.app/Contents/Resources/plugin_openssl.dylib'
In my build.settings:
plugins = {
["plugin.openssl"] = {publisherId = "com.coronalabs"},
},
Can anybody encounter with this issue.
Thanks
Solved!
At the start of app Corona need to download plugin. But on my workplace proxy blocked downloading.
This is old question, but currently OpenSSL plugin may require VS2013 x86 redistributable https://aka.ms/highdpimfc2013x86enu to work. This will help if your error says `error loading 'plugin_openssl' from file '....\plugin_openssl.dll'. Erro says that it found the dll, but can't load it. Redist would solve the issue.
I'm trying to use ios-cmake to generate Xcode project targeting iOS. However, it cannot find Threads. Here's a simple CMake script for demonstration:
CMAKE_MINIMUM_REQUIRED (VERSION 2.8)
PROJECT (MyCITest)
SET (CMAKE_MODULE_PATH "${CMAKE_SOURCE_DIR}/cmake/modules")
########################
# EDIT: I've also tried adding the lines below prior to posting this question,
# but there doesn't seem to be any effect.
# (http://stackoverflow.com/questions/8386897)
SET (CMAKE_REQUIRED_INCLUDES ${CMAKE_IOS_SDK_ROOT}/usr ${CMAKE_IOS_SDK_ROOT}/usr/include)
SET (CMAKE_CXX_FLAGS "--sysroot=${CMAKE_IOS_SDK_ROOT} ${CMAKE_CXX_FLAGS}")
SET (CMAKE_C_FLAGS "--sysroot=${CMAKE_IOS_SDK_ROOT} ${CMAKE_C_FLAGS}")
########################
FIND_PACKAGE (ZLIB REQUIRED)
FIND_PACKAGE (LibXml2 REQUIRED)
FIND_PACKAGE (Threads REQUIRED)
Running CMake from the terminal:
cmake .. -DCMAKE_TOOLCHAIN_FILE=../cmake/toolchains/iOS.cmake -GXcode
This is the output I got:
-- Toolchain using default iOS SDK: /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS6.0.sdk
-- Found ZLIB: /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS6.0.sdk/usr/lib/libz.dylib (found version "1.2.5")
-- Found LibXml2: /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS6.0.sdk/usr/lib/libxml2.dylib (found version "2.7.8")
-- Looking for include file pthread.h
-- Looking for include file pthread.h - not found
CMake Error at cmake/modules/FindPackageHandleStandardArgs.cmake:97 (MESSAGE):
Could NOT find Threads (missing: Threads_FOUND)
Call Stack (most recent call first):
cmake/modules/FindPackageHandleStandardArgs.cmake:288 (_FPHSA_FAILURE_MESSAGE)
cmake/modules/FindThreads.cmake:166 (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
CMakeLists.txt:8 (FIND_PACKAGE)
-- Configuring incomplete, errors occurred!
I've already triple-checked that pthread.h is located in /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS6.0.sdk/usr/include, and besides, it located ZLib and LibXML2 without a problem, so I'm not sure what I'm doing wrong.
> cmake --version
cmake version 2.8.10.2
None of these solutions seem to work. I found the only thing that consistently worked for me was to set the variables that FindThreads.cmake sets. In other words, define the following in your toolchain file:
set(CMAKE_THREAD_LIBS_INIT "-lpthread")
set(CMAKE_HAVE_THREADS_LIBRARY 1)
set(CMAKE_USE_WIN32_THREADS_INIT 0)
set(CMAKE_USE_PTHREADS_INIT 1)
The problem is indeed due to the call to try_compile failing in FindThreads.cmake. But for me setting CMAKE_CXX_COMPILER_WORKS was not enough. Instead, I changed the type of test performed by try_compile from trying to build an executable to trying to build a static library, by putting this in the toolchain file:
set(CMAKE_TRY_COMPILE_TARGET_TYPE STATIC_LIBRARY)
[Sept 2019] Fix for XCode 11 & iOS 13
As explained here.
Need to use XCODE_ATTRIBUTE_CODE_SIGNING_ALLOWED instead of CMAKE_XCODE_ATTRIBUTE_CODE_SIGNING_REQUIRED below to make this work:
set(CMAKE_TRY_COMPILE_PLATFORM_VARIABLES "XCODE_ATTRIBUTE_CODE_SIGNING_ALLOWED")
set(XCODE_ATTRIBUTE_CODE_SIGNING_ALLOWED "NO")
find_package(Threads REQUIRED)
unset(CMAKE_TRY_COMPILE_PLATFORM_VARIABLES)
unset(XCODE_ATTRIBUTE_CODE_SIGNING_ALLOWED)
[Aug 2019]: Info from CMake's issue tracker
The issue was discussed here and explained by #alcroito. It does not use the custom ios-cmake toolchain but the new native iOS toolchain (CMake 3.14+) but the issue is the same.
Source of the issue
When using the Xcode generator, it will try to sign applications by default. When looking for Threads, CMake calls FindThreads.cmake which will call a TRY_COMPILE test that Xcode will try to sign and fail at.
Proper solution:
Disable signing for the try_compile within FindThreads (seen here):
set(CMAKE_TRY_COMPILE_PLATFORM_VARIABLES "CMAKE_XCODE_ATTRIBUTE_CODE_SIGNING_REQUIRED")
set(CMAKE_XCODE_ATTRIBUTE_CODE_SIGNING_REQUIRED "NO")
find_package(Threads REQUIRED)
unset(CMAKE_TRY_COMPILE_PLATFORM_VARIABLES)
unset(CMAKE_XCODE_ATTRIBUTE_CODE_SIGNING_REQUIRED)
Other solutions in this thread
Make the binary of that try_compile static, which won't be signed (seen here). That's not great since it should be an executable and not a static lib.
Pass proper information to be able to sign the try_compile executable (seen here). That actually would not work for me.
Skip try_compile (seen here): not quite safe since you'll skip all your compiler tests. That would not work for me either.
Hardcode Threads by overriding what FindThreads does (seen here): quite a dirty workaround.
It turns out that the iOS toolchain currently doesn't support TRY_COMPILE, which is used by CheckIncludeFiles.cmake, which is in turn used by FindThreads.cmake. The toolchain is currently set to skip TRY_COMPILE by using:
set (CMAKE_CXX_COMPILER_WORKS TRUE)
set (CMAKE_C_COMPILER_WORKS TRUE)
Reference: http://code.google.com/p/ios-cmake/issues/detail?id=1&can=1
You can fix try_compile command using next variables in toolchain:
# toolchain.cmake
set(CMAKE_MACOSX_BUNDLE YES)
set(CMAKE_OSX_SYSROOT "iphoneos")
set(CMAKE_XCODE_ATTRIBUTE_CODE_SIGN_IDENTITY "iPhone Developer")
set(MACOSX_BUNDLE_GUI_IDENTIFIER "com.example")
And minimalistic example:
# CMakeLists.txt
cmake_minimum_required(VERSION 2.8)
project(Foo)
find_package(Threads REQUIRED)
add_executable(foo foo.cpp)
Generate output:
> cmake -H. -B_builds -DCMAKE_TOOLCHAIN_FILE=toolchain.cmake -GXcode
...
-- Looking for include file pthread.h
-- Looking for include file pthread.h - found
-- Looking for pthread_create
-- Looking for pthread_create - found
-- Found Threads: TRUE
...
Complete solution
Just to mention, I also encountered the same problem in my project. I commented out the find_package(Threads REQUIRED) line and generate the Xcode proejct. The codes compiled without errors. Maybe Xcode could automatically link with posix thread library.
The solution for me was a combination of the 2 answers before me.
Comment out the 2 lines that disable try_compile
# Skip the platform compiler checks for cross compiling
set (CMAKE_CXX_COMPILER_WORKS TRUE)
set (CMAKE_C_COMPILER_WORKS TRUE)
Then add this to the top of the IOS.cmake toolchain file.
set(MACOSX_BUNDLE_GUI_IDENTIFIER com.example)
set(CMAKE_MACOSX_BUNDLE YES)
set(CMAKE_XCODE_ATTRIBUTE_CODE_SIGN_IDENTITY "iPhone Developer")
My problem is similar with this: http://www.eclipse.org/forums/index.php/m/649323/
I created a cmake project, and used
cmake .. -G "Eclipse CDT4 - Unix Makefiles"
to create a Eclipse CDT4 project.
But in the CDT IDE, the standard include paths are not listed, and all STL or system build-in header files include directives are marked as "cannot be resolved", so the "Open Declaration" or other a lot of operation cannot be done.
However, I could compile it without any problems.
My co-worker also has a cmake project, but it's very complicated. The CDT project generated from his cmake project DOES have the system includes. But his cmake is way too complicated, and he told me that he didn't do anything special to include the system paths.
Can anyone help me out? Thanks.
My Main CMakeLists.txt:
CMake_Minimum_Required(VERSION 2.8)
# Some settings
Set(CMAKE_ALLOW_LOOSE_LOOP_CONSTRUCTS ON)
CMake_Policy(SET CMP0015 NEW)
#Include(CMakeProcedures.cmake)
#CheckEnvironment()
# Set the compiler and its version if needed
# Create the project
Project(MyProjectName CXX)
# Set the compiler
Set(CMAKE_CXX_COMPILER /usr/bin/g++)
# Detect whether we are in-source
If (CMAKE_SOURCE_DIR STREQUAL CMAKE_BINARY_DIR)
Message(FATAL_ERROR "In-source building is not allowed! Please create a 'build' folder and then do 'cd build; cmake ..'")
EndIf()
# Set the output dirs
Set(EXECUTABLE_OUTPUT_PATH ${PROJECT_BINARY_DIR}/bin)
Set(LIBRARY_OUTPUT_PATH ${PROJECT_BINARY_DIR}/lib)
# Add source subdirs to the build
Add_Subdirectory(src)
# Add_Subdirectory(test EXCLUDE_FROM_ALL)
Peter
One workaround is to manually add these to the CDT IDE:
/usr/include/c++/4.5
/usr/include/c++/4.5/backward
/usr/include/c++/4.5/i686-linux-gnu
/usr/include/i386-linux-gnu
/usr/lib/i386-linux-gnu/gcc/i686-linux-gnu/4.5.2/include
/usr/lib/i386-linux-gnu/gcc/i686-linux-gnu/4.5.2/include-fixed
/usr/local/include
But it's not the solution.
I finally figured out that this line is causing the problem:
Project(MyProjectName CXX)
If we remove the optional paramter CXX, life is good.
Can anyone tell me why?
Peter