Re: [Boost-users] Compilation problem with has_binary_operator.hpp on Mac OSX

OK, Just reporting back in the hope that I can help others avoid the pain I've been through with this. My solution to getting Boost, wxWidgets, Crypto++ and an Objective-c++ module all to play happily together on my Mac is as follows: - Boost 1.55.0; - wxWidgets 3.0.0; - Crypto++ 5.6.2; - Xcode 5.0.2, as moving to Apple's version of clang keeps my Objective-c++ module happy; - Needed to use libstdc++ instead of libc++ for all modules as Crypto++ wouldn't build using libc++, but earlier versions of wxWidgets won't build with libstdc++, hence the move to 3.0.0; Thanks to everybody who offered suggestions that took me forward - I can now move onto debugging my own code instead of fighting librariesJ Best wishes. Tim Burgess From: Boost-users [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Tim Burgess Sent: 11 January 2014 14:48 To: boost-users@lists.boost.org Subject: Re: [Boost-users] Compilation problem with has_binary_operator.hpp on Mac OSX I had problems building one of the other libraries I need (wxWidgets) using clang, but I'll get their latest svn and see if it's resolved. If so, I'll try clang with my Xcode 4.6 and see where that takes me. Thanks. Best wishes. Tim Burgess From: Boost-users [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Michael Olea Sent: 10 January 2014 16:21 To: boost-users@lists.boost.org Subject: Re: [Boost-users] Compilation problem with has_binary_operator.hpp on Mac OSX On Jan 10, 2014, at 8:08 AM, Tim Burgess wrote: OK, This fix worked for me in clearing the issue around has_binary. However, I'm still having a problem. The module I'm trying to build is an objective-c++ framework and, due to an earlier problem around anonymous enumerations, I was told to use a later version of GCC than Apple's provided version. For this reason I configured GCC 4.8.2 from MacPorts and set up a compiler plug-in for Xcode 4.6 to build my framework using this version of the compiler. I now appear to be in a Catch 22 scenario as GCC 4.8 apparently does not support C blocks, giving me the following first error: NSTask.h:69: Expected unqualified-id before '^' I can clear this by reverting to Apple's GCC 4.2, but then I'll get anonymous enum errors in Boost's decay.h. I'm now way out of my depth and experience, so can anybody please offer any help out of my dilemma? Best wishes. Tim Burgess I don't know if this will help, or if it is even an option for you, but can you try Xcode 5 with clang?