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.
Related
This is what my files look like
My main function is here
I compiled it using the following command:
g++ -std=c++17 main.cpp linkedList.cpp -o main
on MacOS 10.14 using the latest gcc compiler as of 2018.
It looks like the definitions for your template are not visible to the compiler when it is instantiated. You need to move the definitions from linkedList.cpp into the header file, linkedList.hpp.
(Note that C++17 support is still experimental in GCC.)
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'm writing a little self-educational project. It has to do with Clang and LLVM internals hacking.
But while I was investigating the code base and reading documentation, strange things were going on with the build process.
What I am trying to do for starters is to build LLVM and Clang for SPARC target. But this rather simple task turns out to be quiet challenging.
I use sources from the stable release 3.4.2 and folder tree looks like that:
llvm/
...
projects/
...
test-suite <-- test-suite-3.4.src.tar.gz extracted here
tools/
...
clang/ <-- cfe-3.4.2.src.tar.gz extracted here
....
tools/
....
extra <-- clang-tools-extra-3.4.src.tar.gz extracted here
And from the intermediate folder (which lays on the same level as llvm) I call the following:
../llvm/configure --disable-optimized --enable-targets=sparc \
--prefix=/home/wf34/projects/helloClang/built
Surprisingly, resulting clang and llvm cannot deal with SPARC arch.
../built/bin/clang file2.c -S --target=sparc-unknown-linux -emit-llvm -o -
Gives (amongst the others) following line:
clang: warning: unknown platform, assuming -mfloat-abi=soft
Result is the same, if I write just --target=sparc.
Finally, attaching result of the llc --version:
LLVM (http://llvm.org/):
LLVM version 3.3
Optimized build.
Default target: x86_64-pc-linux-gnu
Host CPU: corei7-avx
Registered Targets:
cpp - C++ backend
x86 - 32-bit X86: Pentium-Pro and above
x86-64 - 64-bit X86: EM64T and AMD64
Thank you for your insight and ideas!
Edit
Actually, having all that written, I have a guess that maybe I might have been mistaken while getting and untaring and setting the source from stable release. Maybe I would be better off following manual steps directly and getting source from svn trunk. I will fall back to that option if I won't receive any more meaningful suggestion.
I am trying to compile Sofia-SIP library for iOS for architectures armv6 and armv7 but I am running into problems. Below is what I am doing.
export DEVROOT=/Applications/Xcode_4_6.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer
export SDKROOT=$DEVROOT/SDKs/iPhoneOS6.1.sdk
export CC=$SDKROOT/usr/bin/llvm-gcc-4.2
export CFLAGS="-pipe -no-cpp-precomp -isysroot $SDKROOT -arch armv7"
export LDFLAGS="-syslibroot $SDKROOT -arch armv7"
export CPP=$SDKROOT/usr/bin/llvm-g++-4.2./configure --host=arm-apple-darwin10
sudo ./configure --host=arm-apple-darwin10
RESULT
Password:
configure: WARNING: if you wanted to set the --build type, don't use --host.
If a cross compiler is detected then cross compile mode will be used
checking build system type... x86_64-apple-darwin12.5.0
checking host system type... arm-apple-darwin10
checking target system type... arm-apple-darwin10
checking cached information... ok
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking for arm-apple-darwin10-strip... no
checking for strip... strip
checking whether to enable maintainer-specific portions of Makefiles... no
checking for style of include used by make... GNU
checking for arm-apple-darwin10-gcc... no
checking for gcc... gcc
checking for arm-apple-darwin10-gcc... gcc
checking whether the C compiler works... yes
PROBLEM
I want the script to use llvm-gcc compiler. But instead it is looking for arm-apple-darwin10-gcc which it could not find and then finally ends up using gcc compiler.
I fought with this for a weekend, won the battle (with a lot of help), and have the following to return to the community:
Regarding su_os_nw.c and the
SCDynamicStore: function has been explicitly marked unavailable for iOS
issue:
I was about to give up, but noticed that a fellow named Antonis Tsakirids from Restcomm reported success in integrating Sofia in their iOS SDK.
I then went to their git repository and had a look at their SDK.
In /dependencies/sofia-sip/libsofia-sip-ua/su/ I found the culprit: su_os_nw.c
They elegantly updated
#if defined (__APPLE_CC__)
to
#if defined (__APPLE_CC__) && !defined(TARGET_OS_IPHONE)
This solves it…
…but it does not solve it just by itself…because apparently since Xcode 7, Apple did some toolchain utilities shuffling.
Stuff is not located in “usual” locations anylonger, and MishaBruckman’s $DEVROOT got obsolete.
For instance , I got errors about “ar” not being found.
export DEVROOT="$(xcrun --sdk iphoneos --show-sdk-platform-path)/Developer”
maps to /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer
However, the toolchain utilities (ld, ar, as, nm, ranlib, along with the almighty clang) have been moved to /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin.
I bolded the part that should map to the new $DEVROOT.
Hope this helps someone save 2 weekend days of their life...
…and in the end, the 2 points expressed above were not enough to get out of the woods…Compilation did finish OK and I left it at that initially.
However, today I wanted to actually use the library. Created a new project, imported the library, hit Build and…more suffering…
libsofia-sip-ua.a does not contain bitcode. You must rebuild it with bitcode enabled (Xcode setting ENABLE_BITCODE), obtain an updated library from the vendor, or disable bitcode for this target for architecture armv7.
At first I went “say wha’…?”
what’s this mumbo_jumbo about setting stuff in Xcode? I did things the old_school way, compiling in command line…
what do you mean “obtain an updated library from the vendor”…the “vendor” is me, I’m building the library…
what is this strange bitcode thing, anyway?
After doing my homework regarding bitcode I started wondering what hides behind Xcode’s ENABLE_BITCODE… Turns out it “means” passing the “-fembed-bitcode” flag to clang.
In conclusion, the line
export CFLAGS="-arch ${ARM_ARCH} -mios-version-min=7 -pipe -no-cpp-precomp -isysroot ${SDKROOT} -I${SDKROOT}/usr/include/"
became
export CFLAGS="-arch ${ARM_ARCH} -mios-version-min=7 -fembed-bitcode -pipe -no-cpp-precomp -isysroot ${SDKROOT} -I${SDKROOT}/usr/include/"
Rebuilt Sofia with the new settings, but then it started complaining that even though the main project itself is going ok, it's SUB-LIBRARIES (for example libstun.a) are not compiled with bitcode. A "make clean" got rid of the old garbage and compilation finished ok. Imported the newly produced lib into my Xcode project and everything was ok as well.
And that finally concludes it. Build successful for a project under Xcode 7 / iOS9 integrating Sofia library, in anno domini 2015…
...aaaand...I was still not out of the woods...
As soon I decided to add arm64 architecture to my project, Xcode started again to complain about Sofia:
ignoring file libsofia-sip-ua.a, file was built for archive which is not the architecture being linked (arm64)
Undefined symbols for architecture arm64
Pretty simple, I thought: I'll just replace armv7 with arm64:
export ARM_ARCH="arm64”
After that modification, disaster struck while ./configure-ing:
checking for gcc... /usr/bin/clang
checking for gcc... (cached) /usr/bin/clang
checking whether the C compiler works... no
configure: error: in `/work/fromSourceforge/sofia-sip-1.12.11':
configure: error: C compiler cannot create executables
See `config.log' for more details
The next day was spent figuring out what was wrong (I could not ./configure anylonger, even reverting back to armv7)
stormed stack overflow; no solution helped
checked ad re-checked every path on the system...I was surprised to find out that one can find clang and gcc in 3-4 places throughout macosx, but I digress...
trying to reinstall Xcode Developer Tools
ended up reinstalling Xcode itself...
...nothing helped.
An eagle-eyed colleague spotted what was wrong:
export ARM_ARCH="arm64”
The last quote sign was not "the same" as the first quote sign. The first quote sign is "the correct kind of quote sign".
Even if I didn't touch the second one with my own hand, TextEdit changed it all by itself while I was converting v7 to 64. Apparently it's "a feature", called SmartQuotes. I could not disable it, by the way.
Mental note: NEVER EVER use TextEdit again to edit the .bash_profile file.
Finally, I found myself in the posession of the 64 bit version of Sofia. Plugged it into my Xcode project, aaaaaaand....
ignoring file libsofia-sip-ua.a, file was built for archive which is not the architecture being linked (armv7)
Undefined symbols for architecture armv7
Hmmm...if I build it for 32 bits, it complains about 64 missing...If I build it for 64 bits, it complains about 32 missing...
Turns out there's a way to fuse together multiple libraries into a single "fat" one.
The utility is called lipo and you use it something like this:
lipo -create "path_to_lib_1" "path_to_lib2" -output "path_to_desired_name_of_the_merged_library"
So: SIP-ing along with Sofia, under iOS, as a single library that does both 32 and 64 bits...
Heewhhh...
.....aaaaaaaaand we're still not done...!
Problem: trying to do anything (REGISTER, for instance) promptly resulted in a 503 DNS Error
Cause : Sofia searches for the name servers list in etc/resolv.conf
Obviously, this being iOS, it either does not exist, OR it's outside of the app sandbox.
Solution : it's the second time when this guy, Antonis Tsakiridis, saves my ass. Respectful bow.
First, he talks about what he intends to do.
Second, he shows what he has actually done.
However, the solution exposes a new...
Problem: _res_9_init - undefined symbol for architecture (armv7 or arm64 here, depending on what I happened to have set for ARM_ARCH), while recompiling Sofia
Cause : I don't know. I can only infer from the solution, that the linker needed to be told about the "resolv" library
Solution : added -lresolv in two places:
LDFLAGS (in the .bash_profile file)
in the Xcode "application" project (the one that exercises the library); Targets ---> Linking ---> OtherLinkerFlags
Just like before, although the above solves what it was trying to solve, it also advances us to the next...
Problem: conditional execution of code under #IOS_BUILD (part of AT's solution at first problem) did not take place. Still getting 503 DNS Error...
Cause : I could not figure out for the life of me WHERE IT'S ACTUALLY DEFINED. Of course, defining it anywhere in my own code could have no effect, since Sofia is supposed to be an already compiled dependency; we don't get another chance at the preprocessor crunching through her code.
Solution: I replaced the IOS_BUID #define with an environment variable called IOS_BUILD that has the value...well...IOS_BUILD. I told Xcode about it (I'm trying to use not the word "define" to avoid confusion) at
Product ---> Scheme ---> EditScheme ---> Arguments ---> EnvironmentVariables.
In Sofia, I just substituted #Ifdef IOS_BUILD with calls to getenv() and strcmp().
After all that, behold...REGISTER takes place...
Also, DNS settings are correctly detected everytime I connect the iPhone to another wi-fi, thanks to Sofia's smart "resolver".
Note that llvm-gcc is deprecated; you should be using clang instead:
% ls -l /usr/bin/llvm-gcc
lrwxr-xr-x 1 root wheel 5 Nov 8 2013 /usr/bin/llvm-gcc# -> clang
The following seems to work for me:
export DEVROOT="$(xcrun --sdk iphoneos --show-sdk-platform-path)/Developer"
export SDKROOT="$(xcrun --sdk iphoneos --show-sdk-path)"
export CC="/usr/bin/clang"
export CXX="/usr/bin/clang++"
export LD="${DEVROOT}/usr/bin/ld"
export AR="${DEVROOT}/usr/bin/ar"
export AS="${DEVROOT}/usr/bin/as"
export NM="${DEVROOT}/usr/bin/nm"
export RANLIB="${DEVROOT}/usr/bin/ranlib"
export LDFLAGS="-L${SDKROOT}/usr/lib/"
export ARM_ARCH="armv7" # or "armv6" and adjust the --host=[...] flag below
export CFLAGS="-arch ${ARM_ARCH} -pipe -no-cpp-precomp -isysroot ${SDKROOT} -I${SDKROOT}/usr/include/"
export CPPFLAGS="${CFLAGS}"
export CXXFLAGS="${CFLAGS}"
Configure:
./configure --host=armv7-apple-darwin
Build:
make
Verify:
file `find . -name \*dylib`
Output:
./libsofia-sip-ua/.libs/libsofia-sip-ua.0.dylib: Mach-O dynamically linked shared library arm
./libsofia-sip-ua/.libs/libsofia-sip-ua.0.dylib.dSYM/Contents/Resources/DWARF/libsofia-sip-ua.0.dylib: Mach-O dSYM companion file arm
./libsofia-sip-ua/.libs/libsofia-sip-ua.dylib: Mach-O dynamically linked shared library arm
Credits:
most flags above were adapted from this question
xcrun command via a comment by Alex Denisov on this page
Notes:
I dropped the -miphoneos-version-min=[...] flag from the other question as I did not think it was relevant to your question; up to you if you want to add it back into CFLAGS.
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")