boost issues (ambigous ref) when upgrading to C++11

Background

---

I have a large program which needs to use a new version of a specific third party library, which has recently been upgraded to require C++11 support (i.e. compiled with GCC with -std=c++11). Additionally, some of the header files for this library apparently make use of C++11 syntax, so I need to upgrade the entire application and its own in-house libraries to compile against a new GCC (i.e. v4.8 or later) with -std=c++11.

The bulk of this work has been trivial, except for libraries that use boost. For legal reasons, I'm currently stuck with Boost 1.60.0, but can potentially change this. I built a new release of Boost 1.60.0, and ran into problems with list_of, which I was able to resolve via:

• #7364 - ambiguity error constructing std::vector from assign::list_of, which pointed to:
• #5419 - assign fails with C++0x compilers, which pointed to:
• Ticket #5419: assign_cxx0x.patch

---

Problem

---

This got me past the bulk of my compilation errors. Now, I seem to have one last recurring thorn in my side, which is effectively a slew of:

note: std::reference_wrapper<_Tp> std::ref(_TP&) .... ref(_Tp& __t)
...
call of overloaded 'ref(Select::Expressions::Code&)' is ambiguous

And:

/opt/libboost_1.60.0/api/boost/phoenix/core/reference.hpp:69:5:
note: const typename boost::phoenix::expression::reference<T>::type
boost::phoenix::ref(T&) [with T = std::vector<long unsigned int>; typename
boost::phoenix::expression::reference<T>::type =
boost::phoenix::actor<boost::proto::exprns_::basic_expr<boost::proto::tagns_::tag::terminal,
boost::proto::argsns_::term<boost::reference_wrapper<std::vector<long unsigned
int> > >, 0l> >]
     ref(T & t)
call of overloaded 'ref(Select::Expressions::Code&)' is ambiguous

The only information I could find on this is a separate StackOverflow post (which I can no longer find) which noted that C++11 introduces additional default overloads, which is the likely/possible cause of this issue.

Question

---

Is this something that can be resolved by:

• Patching boost?
• Upgrading boost to a newer version?
• Worst-case scenario, is there as simple change that can be uniformly applied to each instance of this error?

My primary goal is to get this building, without having to re-write and re-test a massive piece of boost-heavy code.