tags:

views:

518

answers:

1

So let's say you want to build the Boost "Getting Started" examples and link to them using an Xcode project rather than building at the command line. You try the header-only option and it works fine.

But then you take the example source:

#include <boost/regex.hpp>
#include <iostream>
#include <string>

int main()
{
    std::string line;
    boost::regex pat( "^Subject: (Re: |Aw: )*(.*)" );

    while (std::cin)
    {
        std::getline(std::cin, line);
        boost::smatch matches;
        if (boost::regex_match(line, matches, pat))
            std::cout << matches[2] << std::endl;
    }
}

And you do the following:

  1. Build the boost libraries using ./bjam install
  2. Open Xcode and create a new C++ command line utility project.
  3. Drag libboost_regex.dylib into the Products folder in the Groups & Files treeview (checking the option that allows it copy the file)
  4. Set the project options so that Header Search Paths points to the Boost include folder
  5. Build and Run the project!

Sadly, if you have the console open (Run | Console) you're going to see an error that it can't find the dylib:

dyld: Library not loaded: libboost_regex.dylib
  Referenced from: /Users/matt/Documents/Boost/test/GettingStarted/build/Debug/GettingStarted
  Reason: image not found

So, not knowing a better way to get Xcode to do this, you copy the dylib into your_project/build/debug/ and it runs! Hooray!

Detail-oriented person that you are, you type some stuff into standard in to try it out:

> Subject: foo bar baz
> foo bar baz

And then it segfaults.

Program received signal:  “EXC_BAD_ACCESS”.

ACK!

But have no fear. I know what the problem is! And if nobody beats me to it, I'll post the solution after lunch.

+1  A: 

The problem here is that the default build of boost doesn't play well with your project's debug build. You need to build boost using the debug variant, which is done like this:

./bjam install variant=debug define=_GLIBCXX_DEBUG --with-regex

_GLIBCXX_DEBUG is actually the option in the Xcode project that is causing the conflict.

Then you can link the debug version of the library with your debug Xcode project. (I think this is how the MacPorts precompiled binaries are produced.)

Keep in mind that you can use bjam variant to build multiple targets at the same time.

Also: If it doesn't work after the rebuild, check to be sure that the version of the library you're linking with is actually the one you just rebuilt!

Also: Instead, it might work to remove the _GLIBCXX_DEBUG define from your debug configuration. Double-click your executable in Targets to open the project options, and then remove _GLIBCXX_DEBUG from the preprocessor macros.

Hope this helps.

Matthew Lowe