The compiler file for this compiler is boost/config/compiler/vacpp.hpp. If in doubt about stuff like this, then go to the config tests and look at the config_info results for the compiler in question - it gives you this information and much much more: http://www.boost.org/development/tests/trunk/developer/output/IBM_Canada_Ltd...

Ah yes now I see it. Sorry.

The problem I have is that these compilers are passing the tests for these macros.

It wouldn't be the first time I see the gcc compiler supposedly supporting a feature but breaking if the construct using it is complicated enough. I spent days unsuccessfully trying to make the supposedly MPL-compatible gcc 3.4 compile MSM :(

I've just committed a stricter version of the test for BOOST_NO_NESTED_FRIENDSHIP in case this is an Apple GCC specific problem, as both the updated tests and the msm tests pass for me here with Linux gcc-4.0.4.

Thanks a lot! At least the problem seems to be quite limited.

I haven't tried gcc-4.0.1 on Linux as it means yet another gcc build and install.... I'll leave that to you to try :-)

Is it a variant of the famous "exercise left to the reader"? ;-)

Do you have a stricter test case than we currently use for BOOST_NO_MEMBER_TEMPLATE_FRIENDS that more closely represents MSM's usage?

Looking at your test case, the only possible cause I can imagine is that I'm taking an address of a foo static method in foobar so we could add this: template <class T> class foo { private: template<typename Y> friend class foobar; template<typename Y> friend class foo; template<typename Y> friend bool must_be_friend_proc(const foo<Y>& f); int i; static int my_func(){return 0;} // added public: foo(){ i = 0; } template <class U> foo(const foo<U>& f){ i = f.i; } }; template <class T> class foobar { int i; public: template <class U> foobar(const foo<U>& f) { i = f.i; } // added typedef int (*foofct) (); void test_address() { foofct fct=&foo<int>::my_func;} };

Ah... just looked at the error messages and I'm not sure these are related to that macro or not?

It's hard to spot but I think this is pretty clear: "../boost/msm/back/dispatch_table.hpp", line 174.40: 1540-0300 (S) The "private" member "boost::msm::back::state_machine<<unnamed>::player_,boost::msm::back::NoHistory,boost::msm::back::favor_runtime_speed>::call_no_transition<<unnamed>::play>(library_sm &, int, int, const play &)" cannot be accessed. dispatch_table is made friend so this should not happen.

You could try emailing the IBM test-runners directly - they're quite helpful at tracking down issues like this - just don't tell anyone ;-)

Of course not! It'll stay strictly between us :) I'll take the subject to Michael then. Thanks, Christophe