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")
Related
running cmake -DCMAKE_TOOLCHAIN_FILE=ceres-solver/cmake/iOS.cmake -DCMAKE_CXX_FLAGS="-stdlib=libc++" -DEIGEN_INCLUDE_DIR=/usr/local/Cellar/eigen -DIOS_PLATFORM=OS ceres-solver
gives me these errors
-- Using minimal glog substitute (include): internal/ceres/miniglog
-- Max log level for minimal glog substitute: 2
-- Building without OpenMP, disabling.
-- Neither OpenMP or TBB is enabled, disabling multithreading.
-- Looking for C++ include unordered_map
CMake Error: Generator: execution of make failed. Make command was: "CMAKE_MAKE_PROGRAM" "cmTC_3feba/fast"
-- Looking for C++ include unordered_map - not found
-- Looking for C++ include tr1/unordered_map
CMake Error: Generator: execution of make failed. Make command was: "CMAKE_MAKE_PROGRAM" "cmTC_36cb7/fast"
-- Looking for C++ include tr1/unordered_map - not found
-- Unable to find <unordered_map> or <tr1/unordered_map>.
-- Replacing unordered_map/set with map/set (warning: slower!), try enabling CXX11 option if you expect C++11 to be available.
-- Looking for C++ include memory
CMake Error: Generator: execution of make failed. Make command was: "CMAKE_MAKE_PROGRAM" "cmTC_013b8/fast"
-- Looking for C++ include memory - not found
-- Looking for C++ include tr1/memory
CMake Error: Generator: execution of make failed. Make command was: "CMAKE_MAKE_PROGRAM" "cmTC_bb377/fast"
-- Looking for C++ include tr1/memory - not found
CMake Error at CMakeLists.txt:494 (message):
Unable to find shared_ptr, try enabling CXX11 option if you expect C++11 to
be available.
even if i set CXX11 ON, I would get the same error. What should I do?
Assuming I get this working, do I just run make install to get the libceres.a file?
Much help appreciated.
This is not a C++11 error, notice the error
CMake Error: Generator: execution of make failed. Make command was: "CMAKE_MAKE_PROGRAM" "cmTC_3feba/fast"
CMake is trying to determine the presence of various c++11 features by compiling several short program fragments, and is unable to do so, due to some Make related problems (do you have make installed? Xcore command line tools?) and it ends up concluding that c++11 is not available.
The thing to fix here is to see what is going on with Make on your system.
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 downloaded the source of LuaJIT and compiled it with msvc120.dll (VS 2013 x64). When I run it from the command line I have no problems executing some basic lua. Now the LuaJIT installation guide mentions moving luajit.exe and lua51.dll into their own folder. From there it says to create a lua folder and under that a jit folder with the contents of src/jit moved underneath the newly created jit folder.
From my understanding my folder should look like and contain:
luajit.exe
lua51.dll
/lua
/jit
bc.lua
[rest of jit files]
vmdef.lua
Is this correct or am I missing files?
Now after I built my luajit I tried to wire it up into my luarocks to act as my interpreter using
install.bat /LUA C:\LuaJIT\2.0.3\[folder with above content]
However this cannot find the header files. I then copied over what are the header files into the folder above and that wires it up, but I can never actually get anything to compile when pointed over to LuaJIT. Edit: The error I get is the following,
C:\LuaJIT\2.0.3\bin\lua51.dll : fatal error LNK1107: invalid or corrupt file: cannot read at 0x2D0
Error: Failed installing dependency: https://rocks.moonscript.org/luafilesystem-1.6.2-2.src.rock - Build error: Failed compiling module lfs.dll
Is the correct way to handle this to simply point to my lua binaries and from there leverage LuaJIT to run my files or am I doing something wrong with wiring up LuaJIT and luarocks? The former seems to work for the most part, since I only ran into one library compilation issue, lua-cjson.
I've run on exactly the same problem, but they've found a solution right here:
https://github.com/keplerproject/luafilesystem/issues/22
I knew that for "linking DLLs statically" there is a so-called "export" .lib file, which is passed to the linker (and not the DLL itself).
So, for example, when compiling, LuaRocks was doing this:
cl /nologo /MD /O2 -c -Fosrc/mime.obj -ID:/LuaJIT-2.0.4/include/ src/mime.c -DLUA_COMPAT_APIINTCASTS -DLUASOCKET_DEBUG -DNDEBUG -DLUASOCKET_API=__declspec(dllexport) -DMIME_API=__declspec(dllexport) mime.c
link -dll -def:core.def -out:mime/core.dll D:/LuaJIT-2.0.4/bin/lua51.dll src/mime.obj
My LuaJIT was compiled from source in D:\LuaJIT-2.0.4\src, but I made two folders myself: D:\LuaJIT-2.0.4\include with all *.h files copied from src and D:\LuaJIT-2.0.4\bin with luajit.exe, lua51.dll, and then later lua51.exp and lua51.lib. Still same error, but this was the right track.
Fix
Now, check where your LuaRocks configs are:
luarocks.bat help
Scroll down to a section like:
CONFIGURATION
Lua version: 5.1
Configuration files:
System: D:/luarocks/config-5.1.lua (ok)
User : (... snip ...)
Edit the System configuration file, specifically see the part:
variables = {
MSVCRT = 'VCRUNTIME140',
LUALIB = 'lua51.dll'
}
Here! LUALIB should be the .lib file. If your export lib is alongside the DLL, you just need to change to:
variables = {
MSVCRT = 'VCRUNTIME140',
LUALIB = 'lua51.lib' -- here!
}
Verification
And now:
luarocks.bat install luasocket
(...)
link -dll -def:core.def -out:socket/core.dll D:/LuaJIT-2.0.4/bin/lua51.lib src/luasocket.obj (...)
(...)
luasocket 3.0rc1-2 is now built and installed in D:\luarocks\systree (license: MIT)
Note the first argument passed to the linker.
I've been trying to compile Qt for iOS, but I've been having some crazy problems that noone else seems to be having (at least according to what I read in the past day).
I followed the instructions from this article:article url
I cloned a the latest Qt 4.8 from git: $ git clone git://gitorious.org/qt/qt.git
I made the qt-lighthouse-ios-simulator folder, cd to it.
I ran the long line of code from the article: $ ../qt/configure -qpa -xplatform qpa/macx-iphonesimulator-g++ -arch i386 -developer-build -release -opengl es2 -no-accessibility -no-qt3support -no-multimedia -no-phonon-backend -no-svg -no-webkit -no-scripttools -no-openssl -no-sql-mysql -no-sql-odbc -no-cups -no-iconv -no-dbus -static -nomake tools -nomake demos -nomake docs -nomake examples -nomake translations
opensource license
yes I accept the agreement
I get these errors:
In file included from /System/Library/Frameworks/ApplicationServices.framework/Frameworks/HIServices.framework/Headers/Accessibility.h:13,
from /System/Library/Frameworks/ApplicationServices.framework/Frameworks/HIServices.framework/Headers/HIServices.h:49,
from /System/Library/Frameworks/ApplicationServices.framework/Headers/ApplicationServices.h:34,
from generators/mac/pbuilder_pbx.cpp:56:
/System/Library/Frameworks/ApplicationServices.framework/Frameworks/HIServices.framework/Headers/AXUIElement.h:65: error: CGCharCode has not been declared
/System/Library/Frameworks/ApplicationServices.framework/Frameworks/HIServices.framework/Headers/AXUIElement.h:65: error: CGKeyCode has not been declared
After struggling with this, searching here and there, and finding nothing useful (even nothing about what CGKeyCode or CGCharCode actually are, I decided to "hack" it and just added the definitions to pbuilder_pbx.cpp:
typedef u_int16_t CGCharCode; /* Character represented by event, if any */
typedef u_int16_t CGKeyCode; /* Virtual keycode for event */
Then another file couldn't compile, with the same errors. After adding them to a couple of files, I eventually added them to qcore_mac_p.h, then some files complained that they didn't know what u_int16_t was, so I added
typedef unsigned short u_int16_t; /* compile, god damn you!!! */
to the same header.
Now everything compiled but there was this linker error:
ld: in /System/Library/Frameworks//CoreGraphics.framework/CoreGraphics, missing required architecture x86_64 in file for architecture x86_64
Here's where I'm stuck. Any help?
Additional information:
gcc --version : i686-apple-darwin10-g++-4.2.1
iOS SDK: I have both 4.2 and 4.3
OS X version: 10.6.7
Xcode version (if it matters): 4.0.2
The problem somehow magically doesn't exist, when I tried the same thing on a different Mac with OS X 10.7.1
I have no idea how and why, but now qmake compiles and links.
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