I’ve been using Boost as a framework built from Pete Goodliffe’s script for quite some time. Works great. Recently I have hit a problem that can be reproduced by dropping the following code into the viewDidLoad of a view controller in an otherwise brand new XCode project:
#include "boost/filesystem/path.hpp"
#include "boost/filesystem/operations.hpp"
- (void)viewDidLoad
{
[super viewDidLoad];
boost::filesystem::path path("/var/mobile/Applications/.../Documents/somefile.txt");
bool b = boost::filesystem::exists(path);
}
This results in EXC_BAD_ACCESS when the path object is destroyed (the problem occurs in the destructor of the basic_string member of path). Has anyone else run into this problem? Everything is built with the same SDK and visibility settings are the same on test project and framework. Inside ::exists, the only function called on path is .c_str(), which I can call in my code with no problem. It passes the result of .c_str() to ::stat, which I can also call successfully. It seems like a runtime mismatch of some sort. Any ideas?
Pete Goodliffe’s script builds boost using gcc, which in the current SDK is llvm-gcc. The Boost.Build system detects gcc and enables a set of visibility macros for certain things, notably some of the exception macros used by the filesystem library when GCC is in use. By default, iOS applications built using the current SDK will use clang. The boost configuration headers also detect clang when it’s in use, and these visibility macros are not configured the same way. This leads to some linker warnings when you use clang to build your application against boost but use a boost library built with gcc, e.g. about vtable and destructor visibility for the exception classes in question. When your string gets passed into one of these classes, as is likely to happen when you call filesystem::exists() you see a crash in the destructor.
For this specific example, you could remedy the problem by building boost with visibility=default, but that’s unlikely to work well for non-trivial applications. So far, it looks like the best bet is to set the compiler to clang++ so that you have the same visibility settings in effect for these classes when you build the library as you do when you build your application. Here’s the user-config.jam I’m currently using with (my modified version of) that script and Xcode 4.2.x. Note that you’ll need to replace $IPHONE_SDKVERSION, ARM_DEV_DIR and SIM_DEV_DIR if you’re not setting those up in your script. For me, they’re 5.0 and the bin directories of the iphone and simulator SDKs, respectively:
So far, that seems to be working well; I’ve not tested enough to completely assure myself there are no clang-related problems with boost, but this looks easier than taking new iPhone projects back to llvm-gcc.