Just information for the community, in case you run into this before it's fixed ...

This is a complex one, but it comes down to being possible to compile a user application where RTT and part of the application has
boost::posix_time::ptime as one size, and other parts of the application have boost::posix_time::ptime as a different size. Great hilarity ensues trying to work out what the backtrace means after the inevitable seg-fault, as the stack has been misused/corrupted along the way.

It's due to RTT defining BOOST_DATE_TIME_POSIX_TIME_STD_CONFIG on OS X , which affects the size of boost::posix_time::ptime. If part of your user application uses RTT (say to get data from a deployer) and signals that data using Qt, the data will have one size. But if part of your user application use only Qt slots to receive that data, and doesn't know that the above flag has silently been set by RTT underneath, then it expects boost types of a different size. Boom - really interesting GUI crashes. In our case the size problem is actually hidden inside Qt's generated moc files, making it even more interesting to find.

For now you can either define BOOST_DATE_TIME_POSIX_TIME_STD_CONFIG globally (which can generate compiler warnings/errors in the latest versions of clang due re-defined values - you need to tweak rtt/os/targets/target-config.h.in to not define the BOOST_XXX flags if they're already defined), or explicitly include RTT in all UI files (beware that RTT headers must come before all Qt headers, otherwise you'll get errors due to Qt defining certain words like "signal"). And also note that RTT headers must come before boost headers in your application, otherwise you run into a different boost error due to nanosecond types. So include in the order RTT, boost, Qt.

This issue does not affect Orocos on Linux.

Ugh ....
S