Boost C++ Libraries: Ticket #11550: Solaris - boost::call_once issues

component changed; owner set

John Maddock — Tue, 18 Aug 2015 16:09:09 GMT

owner set to Anthony Williams
component Building Boost → thread

John Maddock — Thu, 20 Aug 2015 08:06:38 GMT

I believe this has been fixed now in https://github.com/boostorg/thread/pull/60

lcarreon@… — Thu, 20 Aug 2015 11:16:55 GMT

FYI, I tried implementing the code change mentioned above. It is now complaining about this:

"./boost/thread/pthread/once_atomic.hpp", line 168: Error: Overloading ambiguity between "boost::detail::invoke<void, void(*)(rlimit*), rlimit*>(void(*)(rlimit*)&, rlimit*)" and "boost::detail::invoke<void, void(*)(rlimit*), rlimit*&>(void(*)(rlimit*)&, rlimit*&)".

Looking at the line being complained above, I realized it is in the part of the code where there is no support for variadic templates and rvalue references. IMO, this is incorrect because according to the Solaris Studio 12.4 documentation, it does support these two C++11 features in C++11 mode. Only thread related features are missing. I'm not sure if there is a way to distinguish if the compiler is in C++11 mode or not.

Taking the above into consideration, I undid your changes described above and changed the boost/config/compiler/sunpro_cc.hpp file instead to move BOOST_NO_CXX11_VARIADIC_TEMPLATES to affect Solaris Studio 12.3 and below only. This new change has eliminated all the boost::call_once related errors but it did generate signal 11 errors in various libraries as mentioned in a comment in the compiler configuration file. It also generated template argument errors in Boost.Log and Boost.Variant (1 line each).

John Maddock — Thu, 20 Aug 2015 12:15:54 GMT

We've cross posted:

I made a mistake in the original PR, fixed in https://github.com/boostorg/thread/pull/61
I also commented in the above PR about the errors from invoke.

However, the errors from invoke do not occur when building the thread lib, only when building the context lib which I believe has other errors as well, and won't be easy to fix.

BTW, I don't think that enabling a feature (variadic templates) which is known to cause problems is the right solution either.

owner, status changed

viboes — Thu, 20 Aug 2015 22:52:19 GMT

owner changed from Anthony Williams to viboes
status new → assigned

description changed

viboes — Thu, 03 Sep 2015 06:28:50 GMT

description modified (diff)

owner, status changed

viboes — Thu, 03 Sep 2015 06:51:11 GMT

owner changed from viboes to Andrey Semashev
status assigned → new

There is a SUN specific code in

#if !(defined(__SUNPRO_CC) && BOOST_WORKAROUND(__SUNPRO_CC, <= 0x5130))
  template<typename Function>
  inline void call_once(once_flag& flag, BOOST_THREAD_RV_REF(Function) f)

Would this condition be satisfied with your compiler version? Could you show the report of the lines of the overloads that are ambiguous?

Assigning to Andrey in case he has a better understanding as he wrote once_atomic.

Andrey Semashev — Thu, 03 Sep 2015 10:32:04 GMT

Umm, I can see there are lots of changes that I didn't do (the INVOKE part at least), so maybe I'm not the one with the better understanding currently. :)

To me this looks like a compiler bug that should be reported to Oracle. As a quick fix for invoke problem I can suggest #if-ing out the whole invoke.hpp contents for this compiler, so that BOOST_THREAD_PROVIDES_INVOKE is not defined and boost::bind is used instead. A more efficient fix might be to tweak the invoke overloads somehow but to do that it would require a lot more experimenting, which is difficult as I don't have the compiler.

owner, status changed

viboes — Tue, 08 Sep 2015 19:47:55 GMT

owner changed from Andrey Semashev to viboes
status new → assigned

Oh, I see now that the call_once ambiguity has been avoided already.

summary changed

viboes — Wed, 23 Sep 2015 22:23:06 GMT

summary boost::call_once issues → Solaris - boost::call_once issues