[thread] Boost.Thread DSO's may need to link with Boost.Atomic

[Petr Machata <pmachata@…>]

libs/thread/src/pthread/once.cpp includes libs/thread/src/pthread/once_atomic.cpp, which includes boost/atomic.hpp, which (transitively) includes boost/atomic/detail/lockpool.hpp, which, depending on whether BOOST_ATOMIC_FLAG_LOCK_FREE is set, may need external reference to boost::atomics::detail::lockpool::get_lock_for(void const volatile *), defined in libbost_atomic.so.1.54.0.

On most targets, BOOST_ATOMIC_FLAG_LOCK_FREE is set and the external reference is not necessary. On some, such as s390, it's not, and when linking to libboost_thread.so.1.54.0, the linker complains about unsatisfied references to above-mentioned symbol, such as:

/lib64/libboost_thread.so.1.54.0: undefined reference to `boost::atomics::detail::lockpool::get_lock_for(void const volatile*)'

In attached patch, I resolve this by testing whether BOOST_ATOMIC_FLAG_LOCK_FREE is defined. If not, I set up linking of libboost_atomic.so.1.54.0.

[Petr Machata <pmachata@…>]

A fix.

[Petr Machata <pmachata@…>]

Note that this seems to work--on x86_64 this produces no additional DT_NEEDED entry, on a short-circuit build of just Boost.Thread on s390x, this produces additional DT_NEEDED on Boost.Atomic. However, full s390x bootstrap has not yet finished, so I couldn't actually test whether that resolves the original problem (though I expect it to).

[Petr Machata <pmachata@…>]

The bootstrap has finished and I verified that the fix is effective.

[viboes]

Hi, thanks for the patch. I didn't know that we could configure the build in this way. Very interesting.

[viboes]

BTW, how this path works when cross-compiling?

[viboes]

For the time been I will link always with boost_atomic

Committed revision [85464].

[Petr Machata <pmachata@…>]

Replying to viboes:

BTW, how this path works when cross-compiling?

I don't know the details, I'm relying on configure.compile to pick the configured compiler. This is how all the configure checks are done FWIW, so I would certainly hope it just does the right thing here.

[viboes]

Replying to Petr Machata <pmachata@…>:

Replying to viboes:

BTW, how this path works when cross-compiling?

I don't know the details, I'm relying on configure.compile to pick the configured compiler. This is how all the configure checks are done FWIW, so I would certainly hope it just does the right thing here.

The problem I see is that you can not always run the cross compiled exe on the host. Am I missing something?

[Petr Machata <pmachata@…>]

Replying to viboes:

The problem I see is that you can not always run the cross compiled exe on the host.

We're just building it, not running it. Even simply compiling the source (sans linking) would be enough, as all the magic is in a static assert, but I couldn't find how to request that.

[viboes]

Committed revision [85603] on release branch.

[viboes]

Replying to Petr Machata <pmachata@…>:

Replying to viboes:

The problem I see is that you can not always run the cross compiled exe on the host.

We're just building it, not running it. Even simply compiling the source (sans linking) would be enough, as all the magic is in a static assert, but I couldn't find how to request that.

I understand it now.

[Petr Machata <pmachata@…>]

So, do you intend to add the configure check? It seems like an overkill to link with Boost.Atomic just in case, as most platforms won't need it.

[viboes]

Replying to Petr Machata <pmachata@…>:

So, do you intend to add the configure check? It seems like an overkill to link with Boost.Atomic just in case, as most platforms won't need it.

yes, see [85616].

[Petr Machata <pmachata@…>]

Replying to viboes:

yes, see [85616].

Awesome, thanks.

[viboes]

Committed revision [85666].

[Peter Vingelmann <peter@…>]

Sorry for reviving this old issue, but we encountered the same problem again with several gcc 4.7+ cross-compilers. The problem is that atomic/detail/platform.hpp relies on __atomic* intrinsics for certain compiler versions (gcc 4.7+ and clang 3.2+). However, if __GCC_ATOMIC_BOOL_LOCK_FREE is not defined or its value is 1 (where 2 indicates always lock-free, and 1 indicates sometimes lock-free), then BOOST_ATOMIC_FLAG_LOCK_FREE will not be defined in gcc-atomic.hpp, and the external reference to atomic becomes necessary again.

For example, consider this listing of defines for an Android cross-compiler: ​http://slowbutdeadly.blogspot.hu/2013/09/android-prebuilt-gcc-47-builtin-macro.html where __GCC_ATOMIC_BOOL_LOCK_FREE is 1.

We would like to avoid linking with atomic, so I attached a patch which checks if __GCC_ATOMIC_BOOL_LOCK_FREE is 2, before including gcc-atomic.hpp. If the value is not 2, then the other include options are exhausted, before we have to link with atomic (depending on platform support). This solution works well for us on a range of cross-compilers.

Perhaps the issue should also be raised in atomic.

[Peter Vingelmann <peter@…>]

Fix for gcc 4.7+ cross-compilers.

[viboes]

Moving to Boost.Atomic.