POCO on the iPhone

[guenter]

When building POCO for the iPhone, a few things should be taken care of for a smooth ride:

• Build for armv6 and armv7. This ensures you'll get best performance on older (pre 3 GS) and newer (3 GS and newer) devices.
• Build for iPhone Simulator. Simplifies debugging.
• Specify the minimum iPhone SDK version for the target. If you don't do this, you may run into issues like getting the error shown below when launching your app on a device running iOS < 3.2. Since newer devices are very likely running iOS 3.2 or later, specify a mininum iOS version of 3.0 for armv6 and 3.2 for armv7.

Code: Select all

dyld: lazy symbol binding failed: Symbol not found: ___sync_fetch_and_add_4

Code: Select all

# build for iOS device, armv6 and armv7
./configure --config=iPhone --no-tests --no-samples --omit=...
make IPHONE_SDK_VERSION_MIN=3.0 POCO_TARGET_OSARCH=armv6 -s -j4
make IPHONE_SDK_VERSION_MIN=3.2 POCO_TARGET_OSARCH=armv7 -s -j4
# build for simulator
./configure --config=iPhoneSimulator --no-tests --no-samples --omit=...
make -s -j4


In Xcode, drag the required POCO libs ($POCO_BASE/lib/iPhoneOS/armv6/libPocoFoundation.a, etc.) to the Frameworks folder and use conditional build settings ("Add Build Setting Condition") in the Target Search Paths to link the appropriate variants of the POCO libs by setting library search paths accordingly. See the screenshot below for an example.

[intensifi]

Any suggestions for using the debug libraries while using the simulator build?

It looks like I can use either the debug or release libraries, but not both, in the same XCode project and then conditionally use debug/release based on the target.

[guenter]

This can be done by removing the POCO libs from the Frameworks folder in the project.
Under Target Info -> Linking -> Other Linker Flags, you can then specify the names of the libraries to link. As usual, different settings can be specified for Debug and Release (or other) build configurations.

[rakesh]

Any way to get the NetSSL library built for the iPhoneSimulator?

Thanks
Rakesh

[Tom89]

I think this could be related here - I'm using Poco on iPhone and I recently switched to Poco::DirectoryIterator to enumerate files instead of using the platform's cocoa constructs.
The same code works on Windows/MacOSX/Linux.

But, on IOS it does not work.

I am getting a totally undocumented PathNotExisting exception when creating the iterator with any given path (that I'm sure are correct).
Also, Path::current() always returns "/"... so I think this could be a bug in Poco or in how I built it for IOS.

Any tips?

[guenter]

iPhone applications are sandboxed which means that every iPhone application runs under its own user ID and chroot environment. Therefore, the current working directory of any application is always the root directory (within the application's sandbox). The paths you can access with standard POSIX file I/O functions (including POCO's) are limited. Generally, you cannot access any directory or file outside of your application's sandbox. What path do you try to access?

[Tom89]

iPhone applications are sandboxed which means that every iPhone application runs under its own user ID and chroot environment. Therefore, the current working directory of any application is always the root directory (within the application's sandbox). The paths you can access with standard POSIX file I/O functions (including POCO's) are limited. Generally, you cannot access any directory or file outside of your application's sandbox. What path do you try to access?

I am trying to access a path that was available when using Cocoa's methods, such as NSBundle ones, I'm sure of that because using POCO was part of a refactoring.
It is a directory in the root level of the NSBundle, in the same folder as the executable itself.
Other code in my project uses relative addresses (freads, Cocoa methods, Ogg Vorbis, other), so I'm quite sure that the root directory is actually the root directory of the NSBundle.

Still, Path::current() returns "/", that is obviously incorrect as it's the filesystem root.
On the other hand the absolute path works perfectly, for example if I try to load a folder at the path "./data", this won't work

Code: Select all

Poco::DirectoryIterator itr( "data" );

Code: Select all

Poco::DirectoryIterator itr( "./data" );

while this will work

Code: Select all

Poco::DirectoryIterator itr( toString( [[NSBundle mainBundle] bundlePath ] +  "/data" );

But they both should work just fine!

[guenter]

Path::current() directly calls getcwd(), and this returns "/". Generally, on the iPhone you should not use relative directories. Always use the relevant Cocoa Touch functions (e.g., NSSearchPathForDirectoriesInDomains) to obtain the absolute paths of the various directories (e.g., Bundle, Documents, etc.).

[jdswain]

If you're on Lion and using Xcode 4.2 with the latest iOS SDK's then you'll need to make a small change to this file to build your libraries:

Code: Select all

build/config/iPhone


Change this:

Code: Select all

CC      = $(shell ls $(TOOL_PREFIX)/gcc-$(GCC_VER)* | tail -1)
CXX      = $(shell ls $(TOOL_PREFIX)/g++-$(GCC_VER)* | tail -1)


to this:

Code: Select all

CC      = $(shell ls $(TOOL_PREFIX)/llvm-gcc-$(GCC_VER)* | tail -1)
CXX      = $(shell ls $(TOOL_PREFIX)/llvm-g++-$(GCC_VER)* | tail -1)


This will change the compiler to llvm-gcc, which is probably the best option. It appears that standard gcc-4.2 is still available, but the file naming convention has changed, which breaks the script. This is interesting as the gcc-4.2 option seems to have been removed in Xcode. I'm reluctant to move to llvm/clang fully at present as I've had some crashes using the latest Apple compilers.

Another step that may be useful is to make universal libraries out of the arm6/arm7 builds. You can do this with the lipo tool using a command like this:

Code: Select all

mkdir lib/iPhoneOS/arm
lipo -create lib/iPhoneOS/armv6/libPocoFoundation.a lib/iPhoneOS/armv7/libPocoFoundation.a -output lib/iPhoneOS/arm/libPocoFoundation.a


You'll need to do this for each library you use.

Or if you want to make your Xcode config really simple, at the expense of larger files sizes, you could even include the simulator builds into one file:

Code: Select all

mkdir lib/iPhoneOS/universal
lipo -create lib/iPhoneOS/armv6/libPocoFoundation.a lib/iPhoneOS/armv7/libPocoFoundation.a lib/iPhoneSimulator/i686/libPocoFoundation.a -output lib/iPhoneOS/universal/libPocoFoundation.a


[jasperblues]

Have built POCO for iPhone and created a universal library using lipo. . . . but when building my app, I noticed that zlib is compiled in, so I have to unlink zlib. . . What are the implications of this?