Igor R wrote:
Thanks a lot for your answer, you pointed me in the direction I didn't think of: __thumb__! Actually, my project was compiled with Thumb switched on - which is default in XCode. On the other hand, boost libraries was built with their default compiler switches for this platform, as defined in boost.build/bjam configuration (probably, thumb off?). Anyway, now I switched off Thumb in my project settings, and everything began to move as expected!
Thanks for tracking this down.
Is your application multithreaded, or does even a simple uncontended use of boost::detail::spinlock or boost::detail::spinlock_pool fail?
My application is multithreaded, but spinlock_pool was hanging in absolutely "uncontended" places - like in regex, which I use in 1 thread only.
I still don't understand why it behaved like this - afterall, if thumb-enabled code doesn't support such a spinlock, it should crash, and if it does support, it should work...
The ARM-specific implementation is only used when __thumb__ is not defined: #if defined(__GNUC__) && defined( __arm__ ) && !defined( __thumb__ ) # include <boost/smart_ptr/detail/spinlock_gcc_arm.hpp> because Thumb doesn't support the swp instruction and spinlock_gcc_arm doesn't compile. This causes an ABI mismatch when Thumb and non-Thumb files are linked together; the inlined code is trying to lock a spinlock that doesn't exist.