Boost C++ Libraries: Ticket #9041: [thread] Boost.Thread DSO's may need to link with Boost.Atomic

attachment set

Fri, 23 Aug 2013 22:44:47 GMT

attachment → boost-1.54.0-thread-link_atomic.patch

A fix.

Fri, 23 Aug 2013 22:47:15 GMT

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).

Sat, 24 Aug 2013 10:04:15 GMT

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

owner, status changed

viboes — Sun, 25 Aug 2013 14:48:13 GMT

owner changed from Anthony Williams to viboes
status new → assigned

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

viboes — Sun, 25 Aug 2013 15:04:02 GMT

BTW, how this path works when cross-compiling?

viboes — Sun, 25 Aug 2013 15:16:35 GMT

For the time been I will link always with boost_atomic

Committed revision [85464].

milestone changed

viboes — Sun, 25 Aug 2013 15:16:55 GMT

milestone To Be Determined → Boost 1.55.0

Mon, 26 Aug 2013 14:29:24 GMT

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 — Mon, 26 Aug 2013 21:27:28 GMT

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?

Mon, 26 Aug 2013 23:11:26 GMT

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 — Sun, 08 Sep 2013 09:55:15 GMT

Committed revision [85603] on release branch.

viboes — Sun, 08 Sep 2013 09:58:27 GMT

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.

Mon, 09 Sep 2013 13:49:31 GMT

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 — Mon, 09 Sep 2013 18:03:48 GMT

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].

Mon, 09 Sep 2013 20:11:50 GMT

Replying to viboes:

yes, see [85616].

Awesome, thanks.

status changed; resolution set

viboes — Sat, 14 Sep 2013 14:24:04 GMT

status assigned → closed
resolution → fixed

Committed revision [85666].

Tue, 14 Jan 2014 01:00:30 GMT

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.

attachment set

Tue, 14 Jan 2014 01:01:35 GMT

attachment → boost-1.55.0-atomic-check_lock_free_flag.patch

Fix for gcc 4.7+ cross-compilers.

component changed

viboes — Fri, 17 Jan 2014 20:56:33 GMT

component thread → atomic

Moving to Boost.Atomic.