| Message ID | 20180713173026.2389-1-fontaine.fabrice@gmail.com |
|---|---|
| State | Superseded |
| Headers | show |
| Series | [1/1] boost: thread needs atomic if GCC has bug 64735 | expand |
Hello Fabrice, On Fri, 13 Jul 2018 19:30:26 +0200, Fabrice Fontaine wrote: > When gcc has bug 64735, lock-free atomic ints are not supported: > - lockfree boost::atomic_flag : no > > As a result, boost thread needs boost atomic: > output/host/usr/bin/nios2-linux-readelf -d output/staging/usr/lib/libboost_thread.so > > Dynamic section at offset 0x2cee0 contains 32 entries: > Tag Type Name/Value > 0x00000001 (NEEDED) Shared library: [libboost_system.so.1.67.0] > 0x00000001 (NEEDED) Shared library: [libboost_atomic.so.1.67.0] > > Fixes: > - http://autobuild.buildroot.net/results/5a7db292f1365f27e32695527701d5b827f60092 > - http://autobuild.buildroot.net/results/413dff87f5329d3c5180167a8711cdedea5dec67 > - http://autobuild.buildroot.net/results/a7eb4cbcdbd9412c344f45336dec58c82e84dab9 > > Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com> You'll probably find me annoying, but I'd like to have more details on how this is related to BR2_TOOLCHAIN_HAS_GCC_BUG_64735. I looked into the Boost build system a bit, and here is what I collected. In libs/thread/build/Jamfile.v2, there is the following snippet: if ! [ configure.builds has_atomic_flag_lockfree : $(properties) : "lockfree boost::atomic_flag" ] { result += <library>/boost/atomic//boost_atomic ; } So, the boost_atomic library gets added to the build if has_atomic_flag_lockfree isn't set. This macro is set by this line in the same file: exe has_atomic_flag_lockfree : ../build/has_atomic_flag_lockfree_test.cpp ; So presumably, it builds has_atomic_flag_lockfree_test.cpp, and depending on that decides if atomic_flag_lockfree is available or not. This ./libs/thread/build/has_atomic_flag_lockfree_test.cpp file contains: #include "../../../boost/atomic.hpp" #include "../../../boost/static_assert.hpp" int main(int argc, char *argv[]) { BOOST_STATIC_ASSERT(BOOST_ATOMIC_FLAG_LOCK_FREE); return 0; } So basically, it tests if BOOST_ATOMIC_FLAG_LOCK_FREE is non-zero. And then, things get crazy, because the definition of BOOST_ATOMIC_FLAG_LOCK_FREE depends on lots of other macros. But to me, there is no evidence that this is related to gcc bug 64735. To illustrate this, you can build the following defconfig. It uses a gcc 8.x NIOS2 toolchain, which is not affected by BR2_TOOLCHAIN_HAS_GCC_BUG_64735, and still libboost_thread implies building libboost_atomic. Therefore, the problem is not related to BR2_TOOLCHAIN_HAS_GCC_BUG_64735 :-/ BR2_nios2=y BR2_TOOLCHAIN_EXTERNAL=y BR2_TOOLCHAIN_EXTERNAL_CUSTOM=y BR2_TOOLCHAIN_EXTERNAL_DOWNLOAD=y BR2_TOOLCHAIN_EXTERNAL_URL="http://toolchains.bootlin.com/downloads/releases/toolchains/nios2/tarballs/nios2--glibc--bleeding-edge-2018.06-1.tar.bz2" BR2_TOOLCHAIN_EXTERNAL_GCC_8=y BR2_TOOLCHAIN_EXTERNAL_HEADERS_4_14=y BR2_TOOLCHAIN_EXTERNAL_CUSTOM_GLIBC=y BR2_TOOLCHAIN_EXTERNAL_CXX=y BR2_INIT_NONE=y BR2_SYSTEM_BIN_SH_NONE=y # BR2_PACKAGE_BUSYBOX is not set BR2_PACKAGE_BOOST=y BR2_PACKAGE_BOOST_THREAD=y # BR2_TARGET_ROOTFS_TAR is not set Best regads, Thomas
Hello Fabrice, Have you had the chance to look into the below issue and questions ? boost is now the #1 failure reason in the autobuilders, so it is becoming important to fix it soon. Thanks! Thomas On Sat, 14 Jul 2018 23:05:47 +0200, Thomas Petazzoni wrote: > Hello Fabrice, > > On Fri, 13 Jul 2018 19:30:26 +0200, Fabrice Fontaine wrote: > > When gcc has bug 64735, lock-free atomic ints are not supported: > > - lockfree boost::atomic_flag : no > > > > As a result, boost thread needs boost atomic: > > output/host/usr/bin/nios2-linux-readelf -d output/staging/usr/lib/libboost_thread.so > > > > Dynamic section at offset 0x2cee0 contains 32 entries: > > Tag Type Name/Value > > 0x00000001 (NEEDED) Shared library: [libboost_system.so.1.67.0] > > 0x00000001 (NEEDED) Shared library: [libboost_atomic.so.1.67.0] > > > > Fixes: > > - http://autobuild.buildroot.net/results/5a7db292f1365f27e32695527701d5b827f60092 > > - http://autobuild.buildroot.net/results/413dff87f5329d3c5180167a8711cdedea5dec67 > > - http://autobuild.buildroot.net/results/a7eb4cbcdbd9412c344f45336dec58c82e84dab9 > > > > Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com> > > You'll probably find me annoying, but I'd like to have more details on > how this is related to BR2_TOOLCHAIN_HAS_GCC_BUG_64735. > > I looked into the Boost build system a bit, and here is what I > collected. > > In libs/thread/build/Jamfile.v2, there is the following snippet: > > if ! [ configure.builds has_atomic_flag_lockfree > : $(properties) : "lockfree boost::atomic_flag" ] { > result += <library>/boost/atomic//boost_atomic ; > } > > So, the boost_atomic library gets added to the build if > has_atomic_flag_lockfree isn't set. This macro is set by this line in > the same file: > > exe has_atomic_flag_lockfree : ../build/has_atomic_flag_lockfree_test.cpp ; > > So presumably, it builds has_atomic_flag_lockfree_test.cpp, and > depending on that decides if atomic_flag_lockfree is available or not. > This ./libs/thread/build/has_atomic_flag_lockfree_test.cpp file contains: > > > #include "../../../boost/atomic.hpp" > #include "../../../boost/static_assert.hpp" > > int main(int argc, char *argv[]) > { > BOOST_STATIC_ASSERT(BOOST_ATOMIC_FLAG_LOCK_FREE); > return 0; > } > > So basically, it tests if BOOST_ATOMIC_FLAG_LOCK_FREE is non-zero. And > then, things get crazy, because the definition of > BOOST_ATOMIC_FLAG_LOCK_FREE depends on lots of other macros. > > But to me, there is no evidence that this is related to gcc bug 64735. > > To illustrate this, you can build the following defconfig. It uses a > gcc 8.x NIOS2 toolchain, which is not affected by > BR2_TOOLCHAIN_HAS_GCC_BUG_64735, and still libboost_thread implies > building libboost_atomic. Therefore, the problem is not related to > BR2_TOOLCHAIN_HAS_GCC_BUG_64735 :-/ > > BR2_nios2=y > BR2_TOOLCHAIN_EXTERNAL=y > BR2_TOOLCHAIN_EXTERNAL_CUSTOM=y > BR2_TOOLCHAIN_EXTERNAL_DOWNLOAD=y > BR2_TOOLCHAIN_EXTERNAL_URL="http://toolchains.bootlin.com/downloads/releases/toolchains/nios2/tarballs/nios2--glibc--bleeding-edge-2018.06-1.tar.bz2" > BR2_TOOLCHAIN_EXTERNAL_GCC_8=y > BR2_TOOLCHAIN_EXTERNAL_HEADERS_4_14=y > BR2_TOOLCHAIN_EXTERNAL_CUSTOM_GLIBC=y > BR2_TOOLCHAIN_EXTERNAL_CXX=y > BR2_INIT_NONE=y > BR2_SYSTEM_BIN_SH_NONE=y > # BR2_PACKAGE_BUSYBOX is not set > BR2_PACKAGE_BOOST=y > BR2_PACKAGE_BOOST_THREAD=y > # BR2_TARGET_ROOTFS_TAR is not set > > Best regads, > > Thomas
Dear Thomas, 2018-07-28 22:53 GMT+02:00 Thomas Petazzoni <thomas.petazzoni@bootlin.com>: > Hello Fabrice, > > Have you had the chance to look into the below issue and questions ? > boost is now the #1 failure reason in the autobuilders, so it is > becoming important to fix it soon. > > Thanks! > > Thomas > > On Sat, 14 Jul 2018 23:05:47 +0200, Thomas Petazzoni wrote: > > Hello Fabrice, > > > > On Fri, 13 Jul 2018 19:30:26 +0200, Fabrice Fontaine wrote: > > > When gcc has bug 64735, lock-free atomic ints are not supported: > > > - lockfree boost::atomic_flag : no > > > > > > As a result, boost thread needs boost atomic: > > > output/host/usr/bin/nios2-linux-readelf -d > output/staging/usr/lib/libboost_thread.so > > > > > > Dynamic section at offset 0x2cee0 contains 32 entries: > > > Tag Type Name/Value > > > 0x00000001 (NEEDED) Shared library: > [libboost_system.so.1.67.0] > > > 0x00000001 (NEEDED) Shared library: > [libboost_atomic.so.1.67.0] > > > > > > Fixes: > > > - http://autobuild.buildroot.net/results/5a7db292f1365f27e3269 > 5527701d5b827f60092 > > > - http://autobuild.buildroot.net/results/413dff87f5329d3c51801 > 67a8711cdedea5dec67 > > > - http://autobuild.buildroot.net/results/a7eb4cbcdbd9412c344f4 > 5336dec58c82e84dab9 > > > > > > Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com> > > > > You'll probably find me annoying, but I'd like to have more details on > > how this is related to BR2_TOOLCHAIN_HAS_GCC_BUG_64735. > > > > I looked into the Boost build system a bit, and here is what I > > collected. > > > > In libs/thread/build/Jamfile.v2, there is the following snippet: > > > > if ! [ configure.builds has_atomic_flag_lockfree > > : $(properties) : "lockfree boost::atomic_flag" ] { > > result += <library>/boost/atomic//boost_atomic ; > > } > > > > So, the boost_atomic library gets added to the build if > > has_atomic_flag_lockfree isn't set. This macro is set by this line in > > the same file: > > > > exe has_atomic_flag_lockfree : ../build/has_atomic_flag_lockfree_test.cpp > ; > > > > So presumably, it builds has_atomic_flag_lockfree_test.cpp, and > > depending on that decides if atomic_flag_lockfree is available or not. > > This ./libs/thread/build/has_atomic_flag_lockfree_test.cpp file > contains: > > > > > > #include "../../../boost/atomic.hpp" > > #include "../../../boost/static_assert.hpp" > > > > int main(int argc, char *argv[]) > > { > > BOOST_STATIC_ASSERT(BOOST_ATOMIC_FLAG_LOCK_FREE); > > return 0; > > } > > > > So basically, it tests if BOOST_ATOMIC_FLAG_LOCK_FREE is non-zero. And > > then, things get crazy, because the definition of > > BOOST_ATOMIC_FLAG_LOCK_FREE depends on lots of other macros. > I dig a little bit in boost code. From my understanding, BOOST_ATOMIC_FLAG_LOCK_FREE is set to BOOST_ATOMIC_INT8_LOCK_FREE (see boost/atomic/capabilities.hpp): #ifndef BOOST_ATOMIC_BOOL_LOCK_FREE // We store bools in 1-byte storage in all backends #define BOOST_ATOMIC_BOOL_LOCK_FREE BOOST_ATOMIC_INT8_LOCK_FREE #endif #ifndef BOOST_ATOMIC_FLAG_LOCK_FREE #define BOOST_ATOMIC_FLAG_LOCK_FREE BOOST_ATOMIC_BOOL_LOCK_FREE #endif Moreover, BOOST_ATOMIC_INT8_LOCK_FREE is set to 0 (disabled) by default. boost defines this value to 2 (enabled) depending on the architecture / compiler / os by including the correct caps_xxx file: #if !defined(BOOST_ATOMIC_EMULATED) #include BOOST_ATOMIC_DETAIL_BACKEND_HEADER(boost/atomic/detail/caps_) #endif The last file to check is boost/atomic/detail/platform.hpp. boost will try to find if gcc supports atomic by checking if one of _GCC_ATOMIC_xxx_LOCK_FREE is set to 2. If this is not the case, it will try to find it depending on the architecture (x86, arm, ppc, sparcv8plus, sparc_v9, etc ...). Finally, it will check for __GCC_HAVE_SYNC_COMPARE_AND_SWAP_xxx. However with the toolchain you provided below, __GCC_ATOMIC_xxx_LOCK_FREE are all set to 1 (and not 2) and __GCC_HAVE_SYNC_COMPARE_AND_SWAP_xxx are all undefined (see output of output/host/bin/nios2-linux-gcc -dM -E - < /dev/null|sort). As a result, boost does not define BOOST_ATOMIC_DETAIL_BACKEND and libboost_atomic is selected. So I don't know what is the right fix. It seems that BR2_TOOLCHAIN_HAS_SYNC_4 is set to yes even if __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4 is not defined in gcc so I can't add a dependency to it. A quick and probably dirty fix would be to select boost atomic for nios2, m68k, sparcv8 and any other architectures that are "unknown" to boost. I would be happy to get your feedback. > > > But to me, there is no evidence that this is related to gcc bug 64735. > > > > To illustrate this, you can build the following defconfig. It uses a > > gcc 8.x NIOS2 toolchain, which is not affected by > > BR2_TOOLCHAIN_HAS_GCC_BUG_64735, and still libboost_thread implies > > building libboost_atomic. Therefore, the problem is not related to > > BR2_TOOLCHAIN_HAS_GCC_BUG_64735 :-/ > > > > BR2_nios2=y > > BR2_TOOLCHAIN_EXTERNAL=y > > BR2_TOOLCHAIN_EXTERNAL_CUSTOM=y > > BR2_TOOLCHAIN_EXTERNAL_DOWNLOAD=y > > BR2_TOOLCHAIN_EXTERNAL_URL="http://toolchains.bootlin.com/do > wnloads/releases/toolchains/nios2/tarballs/nios2--glibc--ble > eding-edge-2018.06-1.tar.bz2" > > BR2_TOOLCHAIN_EXTERNAL_GCC_8=y > > BR2_TOOLCHAIN_EXTERNAL_HEADERS_4_14=y > > BR2_TOOLCHAIN_EXTERNAL_CUSTOM_GLIBC=y > > BR2_TOOLCHAIN_EXTERNAL_CXX=y > > BR2_INIT_NONE=y > > BR2_SYSTEM_BIN_SH_NONE=y > > # BR2_PACKAGE_BUSYBOX is not set > > BR2_PACKAGE_BOOST=y > > BR2_PACKAGE_BOOST_THREAD=y > > # BR2_TARGET_ROOTFS_TAR is not set > > > > Best regads, > > > > Thomas > > > > -- > Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons) > Embedded Linux and Kernel engineering > https://bootlin.com > Best Regards, Fabrice <div dir="ltr">Dear Thomas,<br><div class="gmail_extra"><br><div class="gmail_quote">2018-07-28 22:53 GMT+02:00 Thomas Petazzoni <span dir="ltr"><<a href="mailto:thomas.petazzoni@bootlin.com" target="_blank">thomas.petazzoni@bootlin.com</a>></span><wbr>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello Fabrice,<br> <br> Have you had the chance to look into the below issue and questions ?<br> boost is now the #1 failure reason in the autobuilders, so it is<br> becoming important to fix it soon.<br> <br> Thanks!<br> <span class="gmail-m_-3262910727091673065gmail-HOEnZb"><font color="#888888"><br> Thomas<br> </font></span><div class="gmail-m_-3262910727091673065gmail-HOEnZb"><div class="gmail-m_-3262910727091673065gmail-h5"><br> On Sat, 14 Jul 2018 23:05:47 +0200, Thomas Petazzoni wrote:<br> > Hello Fabrice,<br> > <br> > On Fri, 13 Jul 2018 19:30:26 +0200, Fabrice Fontaine wrote:<br> > > When gcc has bug 64735, lock-free atomic ints are not supported:<br> > > - lockfree boost::atomic_flag : no<br> > > <br> > > As a result, boost thread needs boost atomic:<br> > > output/host/usr/bin/nios2-linu<wbr>x-readelf -d output/staging/usr/lib/libboos<wbr>t_thread.so<br> > > <br> > > Dynamic section at offset 0x2cee0 contains 32 entries:<br> > > Tag Type Name/Value<br> > > 0x00000001 (NEEDED) Shared library: [libboost_system.so.1.67.0]<br> > > 0x00000001 (NEEDED) Shared library: [libboost_atomic.so.1.67.0]<br> > > <br> > > Fixes:<br> > > - <a href="http://autobuild.buildroot.net/results/5a7db292f1365f27e32695527701d5b827f60092" rel="noreferrer" target="_blank">http://autobuild.buildroot.net<wbr>/results/5a7db292f1365f27e3269<wbr>5527701d5b827f60092</a><br> > > - <a href="http://autobuild.buildroot.net/results/413dff87f5329d3c5180167a8711cdedea5dec67" rel="noreferrer" target="_blank">http://autobuild.buildroot.net<wbr>/results/413dff87f5329d3c51801<wbr>67a8711cdedea5dec67</a><br> > > - <a href="http://autobuild.buildroot.net/results/a7eb4cbcdbd9412c344f45336dec58c82e84dab9" rel="noreferrer" target="_blank">http://autobuild.buildroot.net<wbr>/results/a7eb4cbcdbd9412c344f4<wbr>5336dec58c82e84dab9</a><br> > > <br> > > Signed-off-by: Fabrice Fontaine <<a href="mailto:fontaine.fabrice@gmail.com" target="_blank">fontaine.fabrice@gmail.com</a>> <br> > <br> > You'll probably find me annoying, but I'd like to have more details on<br> > how this is related to BR2_TOOLCHAIN_HAS_GCC_BUG_6473<wbr>5.<br> > <br> > I looked into the Boost build system a bit, and here is what I<br> > collected.<br> > <br> > In libs/thread/build/Jamfile.v2, there is the following snippet:<br> > <br> > if ! [ configure.builds has_atomic_flag_lockfree <br> > : $(properties) : "lockfree boost::atomic_flag" ] { <br> > result += <library>/boost/atomic//boost_<wbr>atomic ; <br> > } <br> > <br> > So, the boost_atomic library gets added to the build if<br> > has_atomic_flag_lockfree isn't set. This macro is set by this line in<br> > the same file:<br> > <br> > exe has_atomic_flag_lockfree : ../build/has_atomic_flag_lockf<wbr>ree_test.cpp ;<br> > <br> > So presumably, it builds has_atomic_flag_lockfree_test.<wbr>cpp, and<br> > depending on that decides if atomic_flag_lockfree is available or not.<br> > This ./libs/thread/build/has_atomic<wbr>_flag_lockfree_test.cpp file contains:<br> > <br> > <br> > #include "../../../boost/atomic.hpp"<br> > #include "../../../boost/static_assert.<wbr>hpp"<br> > <br> > int main(int argc, char *argv[])<br> > {<br> > BOOST_STATIC_ASSERT(BOOST_ATO<wbr>MIC_FLAG_LOCK_FREE);<br> > return 0;<br> > }<br> > <br> > So basically, it tests if BOOST_ATOMIC_FLAG_LOCK_FREE is non-zero. And<br> > then, things get crazy, because the definition of<br> > BOOST_ATOMIC_FLAG_LOCK_FREE depends on lots of other macros.<br></div></div></blockquote><div>I dig a little bit in boost code.<br>From my understanding, BOOST_ATOMIC_FLAG_LOCK_FREE is set to BOOST_ATOMIC_INT8_LOCK_FREE (see boost/atomic/<wbr>capabilities.hpp):<br><br>#ifndef BOOST_ATOMIC_BOOL_LOCK_FREE<br>// We store bools in 1-byte storage in all backends<br>#define BOOST_ATOMIC_BOOL_LOCK_FREE BOOST_ATOMIC_INT8_LOCK_FREE<br>#endif<br><br>#ifndef BOOST_ATOMIC_FLAG_LOCK_FREE<br>#define BOOST_ATOMIC_FLAG_LOCK_FREE BOOST_ATOMIC_BOOL_LOCK_FREE<br>#endif<br><br></div><div>Moreover, BOOST_ATOMIC_INT8_LOCK_FREE is set to 0 (disabled) by default.<br>boost defines this value to 2 (enabled) depending on the architecture / compiler / os by including the correct caps_xxx file:<br><br>#if !defined(BOOST_ATOMIC_EMULATED)<br>#include BOOST_ATOMIC_DETAIL_BACKEND_HEADER(boost/atomic/detail/caps_)<br>#endif<br><br></div><div>The last file to check is boost/atomic/detail/platform.hpp.<br>boost will try to find if gcc supports atomic by checking if one of _GCC_ATOMIC_xxx_LOCK_FREE is set to 2.<br>If this is not the case, it will try to find it depending on the architecture (x86, arm, ppc, sparcv8plus, sparc_v9, etc ...).<br>Finally, it will check for __GCC_HAVE_SYNC_COMPARE_AND_SWAP_xxx.<br></div><div><br></div><div>However with the toolchain you provided below, __GCC_ATOMIC_xxx_LOCK_FREE are all set to 1 (and not 2) and __GCC_HAVE_SYNC_COMPARE_AND_SWAP_xxx are all undefined (see output of output/host/bin/nios2-linux-gcc -dM -E - < /dev/null|sort).<br></div><div>As a result, boost does not define BOOST_ATOMIC_DETAIL_BACKEND and libboost_atomic is selected. <br></div><div><br></div><div>So I don't know what is the right fix. It seems that BR2_TOOLCHAIN_HAS_SYNC_4 is set to yes even if __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4 is not defined in gcc so I can't add a dependency to it.<br></div><div><br>A quick and probably dirty fix would be to select boost atomic for nios2, m68k, sparcv8 and any other architectures that are "unknown" to boost.<br></div><div>I would be happy to get your feedback.<br></div><div><br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail-m_-3262910727091673065gmail-HOEnZb"><div class="gmail-m_-3262910727091673065gmail-h5"> > <br> > But to me, there is no evidence that this is related to gcc bug 64735.<br> > <br> > To illustrate this, you can build the following defconfig. It uses a<br> > gcc 8.x NIOS2 toolchain, which is not affected by<br> > BR2_TOOLCHAIN_HAS_GCC_BUG_6473<wbr>5, and still libboost_thread implies<br> > building libboost_atomic. Therefore, the problem is not related to<br> > BR2_TOOLCHAIN_HAS_GCC_BUG_6473<wbr>5 :-/<br> > <br> > BR2_nios2=y<br> > BR2_TOOLCHAIN_EXTERNAL=y<br> > BR2_TOOLCHAIN_EXTERNAL_CUSTOM=<wbr>y<br> > BR2_TOOLCHAIN_EXTERNAL_DOWNLOA<wbr>D=y<br> > BR2_TOOLCHAIN_EXTERNAL_URL="<a href="http://toolchains.bootlin.com/downloads/releases/toolchains/nios2/tarballs/nios2--glibc--bleeding-edge-2018.06-1.tar.bz2" rel="noreferrer" target="_blank">ht<wbr>tp://toolchains.bootlin.com/do<wbr>wnloads/releases/toolchains/ni<wbr>os2/tarballs/nios2--glibc--ble<wbr>eding-edge-2018.06-1.tar.bz2</a>"<br> > BR2_TOOLCHAIN_EXTERNAL_GCC_8=y<br> > BR2_TOOLCHAIN_EXTERNAL_HEADERS<wbr>_4_14=y<br> > BR2_TOOLCHAIN_EXTERNAL_CUSTOM_<wbr>GLIBC=y<br> > BR2_TOOLCHAIN_EXTERNAL_CXX=y<br> > BR2_INIT_NONE=y<br> > BR2_SYSTEM_BIN_SH_NONE=y<br> > # BR2_PACKAGE_BUSYBOX is not set<br> > BR2_PACKAGE_BOOST=y<br> > BR2_PACKAGE_BOOST_THREAD=y<br> > # BR2_TARGET_ROOTFS_TAR is not set<br> > <br> > Best regads,<br> > <br> > Thomas<br> <br> <br> <br> -- <br> Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons)<br> Embedded Linux and Kernel engineering<br> <a href="https://bootlin.com" rel="noreferrer" target="_blank">https://bootlin.com</a><br> </div></div></blockquote></div>Best Regards,<br><br></div><div class="gmail_extra">Fabrice<br></div></div>
diff --git a/package/boost/Config.in b/package/boost/Config.in index 510ed336e4..42428fab10 100644 --- a/package/boost/Config.in +++ b/package/boost/Config.in @@ -313,6 +313,7 @@ config BR2_PACKAGE_BOOST_TEST config BR2_PACKAGE_BOOST_THREAD bool "boost-thread" + select BR2_PACKAGE_BOOST_ATOMIC if BR2_TOOLCHAIN_HAS_GCC_BUG_64735 select BR2_PACKAGE_BOOST_SYSTEM help Portable C++ multi-threading. C++11, C++14.
When gcc has bug 64735, lock-free atomic ints are not supported: - lockfree boost::atomic_flag : no As a result, boost thread needs boost atomic: output/host/usr/bin/nios2-linux-readelf -d output/staging/usr/lib/libboost_thread.so Dynamic section at offset 0x2cee0 contains 32 entries: Tag Type Name/Value 0x00000001 (NEEDED) Shared library: [libboost_system.so.1.67.0] 0x00000001 (NEEDED) Shared library: [libboost_atomic.so.1.67.0] Fixes: - http://autobuild.buildroot.net/results/5a7db292f1365f27e32695527701d5b827f60092 - http://autobuild.buildroot.net/results/413dff87f5329d3c5180167a8711cdedea5dec67 - http://autobuild.buildroot.net/results/a7eb4cbcdbd9412c344f45336dec58c82e84dab9 Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com> --- package/boost/Config.in | 1 + 1 file changed, 1 insertion(+)