Boost bind AIX xlc io_service run

Question 1

A quick google search suggest that AIX has had issues with overload resolution, especially when templates are involved. As such, it may be worth trying different approaches to reduce the amount of overload resolutions that need to occur.

For example, boost::mem_fn() could be used in place of boost::bind().

std::size_t (io_service::*run)() = &io_service::run;
boost::thread t(boost::mem_fn(run), io_service);

Furthermore, if the compiler is still having issues resolving the overloads, then consider writing a simple functor. The only requirement for the boost::thread() constructor is that the func argument is copyable and func() must be a valid expression.

struct service_runner
{
  explicit service_runner(boost::shared_ptr<boost::asio::io_service> io_service)
    : io_service(io_service)
  {}
  std::size_t operator()() { return io_service->run(); }
  boost::shared_ptr<boost::asio::io_service> io_service;
};

...

boost::thread t((service_runner(io_service)));

Other points to take into consideration:

Prefer compiling conforming code, rather than using compiler flags to allow nonconforming code to compile. In this particular case, io_service::run() is a non-const member function, but the accept_io_service instance argument being bound to it is passed as a constant reference through boost::cref(). Compiler flags, such as gcc's -fpermissive, need to be added to allow for the nonconforming code to compile. Be very careful in using these options, as they may mask serious problems.
Consider passing boost::shared_ptr as the instance handle to the binding calls. This will keep the io_service alive as long as the thread is still running. Otherwise, the io_service could be deleted while a thread is still processing its event loop, resulting in a high chance of invoking undefined behavior.

Question 2

Just curious, are you using the IBM boost library patch for the compiler you are using? http://www-01.ibm.com/support/docview.wss?uid=swg27006911

Question 3

Looking at the messages for the 4 possible candidates attempted, the differences seem to be const related

No candidate is better than "boost::bind<unsigned long,boost::asio::io_service,boost::reference_wrapper<const boost::asio::io_service> >(unsigned long (io_service::*)() const, reference_wrapper<const boost::asio::io_service
>)".
No candidate is better than "boost::bind<unsigned long,boost::asio::io_service,boost::reference_wrapper<const boost::asio::io_service> >(unsigned long (io_service::*)(), reference_wrapper<const boost::asio::io_service>)".
No candidate is better than "boost::bind<unsigned long,boost::asio::io_service,boost::asio::io_service *>(unsigned long (io_service::*)() const, io_service *)".
No candidate is better than "boost::bind<unsigned long,boost::asio::io_service,boost::asio::io_service *>(unsigned long (io_service::*)(), io_service *)".

Since you are using the V11.1 compiler, there are a couple of fixes not enabled by default that you could try using the following options

-qxflag=EnableIssue214PartialOrdering This will enable several fixes related to C++ core language issue 214

-qxflag=FunctionCVTmplArgDeduction2011 This enables some C++2011 clarifications to argument deduction

These changes are the default on the V12.1 compiler, but not on the V11.1 compiler

Question 4

I'm adding additinal response, if someone stumbles upon this problem in general. Because I have found out that this is related to compiler not being able to resolve which function to use, if functions have the same name, but different parameters.

Example:

void test(int a);
void test(int a, int b);

Will not work, and will cause similar error as above.
But changing the name like this:

void test(int a);
void test2(int a, int b);

...will work perfectly fine.

This is definitely less overhead solution than creating wrappers (as I myself was doing till observing this).

Hope that someone will find this useful.