cc-tool: depends on BR2_TOOLCHAIN_HAS_SYNC_4

options_description class from boost's program_options needs __sync_fetch_and_add_4 / __sync_fetch_and_sub_4:

Extract from config.log:
/home/rclinux/rc-buildroot-test/scripts/instance-0/output/host/m68k-buildroot-uclinux-uclibc/sysroot/usr/lib/libboost_program_options.a(options_description.o):
In function
`boost::program_options::options_description_easy_init::operator()(char
const*, boost::program_options::value_semantic const*, char const*)':
options_description.cpp:(.text+0x4240): undefined reference to
`__sync_fetch_and_add_4'
options_description.cpp:(.text+0x42ca): undefined reference to
`__sync_fetch_and_sub_4'
options_description.cpp:(.text+0x42d8): undefined reference to
`__sync_fetch_and_sub_4

Fixes:
- http://autobuild.buildroot.net/results/5677a3fd96217cbb0966063de048401cf1ccf16b

---
 package/cc-tool/Config.in | 2 ++
 1 file changed, 2 insertions(+)

index b2cf97969b..32250db3af 100644
@@ -3,6 +3,7 @@ config BR2_PACKAGE_CC_TOOL
 	depends on BR2_INSTALL_LIBSTDCPP
 	depends on BR2_TOOLCHAIN_HAS_THREADS
 	depends on BR2_USE_WCHAR # boost-filesystem
+	depends on BR2_TOOLCHAIN_HAS_SYNC_4
 	select BR2_PACKAGE_LIBUSB
 	select BR2_PACKAGE_BOOST
 	select BR2_PACKAGE_BOOST_PROGRAM_OPTIONS

@@ -18,4 +19,5 @@ config BR2_PACKAGE_CC_TOOL
 	  http://sourceforge.net/projects/cctool/
 
 comment "cc-tool needs a toolchain w/ C++, threads, wchar"
+	depends on BR2_TOOLCHAIN_HAS_SYNC_4
 	depends on !BR2_INSTALL_LIBSTDCPP || !BR2_TOOLCHAIN_HAS_THREADS || !BR2_USE_WCHAR

2.14.1

Hello Fabrice,

I am not super convinced by this analysis, because:

(1) It really is the boost program options library that needs those sync builtins. So if it really needs, the dependency should be added on BR2_PACKAGE_BOOST_PROGRAM_OPTIONS, and then propagated to all packages that select this, which includes BR2_PACKAGE_CC_TOOL, but not only.

(2) Boost can use other built-ins than __sync builtins. For example on SPARC, BR2_TOOLCHAIN_HAS_SYNC_4 is false, but cc-tool builds just fine. It's because SPARC with recent compilers have BR2_TOOLCHAIN_HAS_ATOMIC that is true, and Boost uses __atomic builtins.

(3) Boost has an emulated atomic operation implementation (which uses locks) which I believe should have been used here if neither __sync nor __atomic builtins are available. But it wasn't used either. Why ?

See boost/atomic/detail/ for the different implementations of atomic operations in Boost.

The problem is that with the crazyness of the bjam build system, I've never been able to figure out Boost decides which atomic implementation to use. If you figure that out, I'll owe you one beer at the next conference :-)

Best regards,

Thomas

Thomas Petazzoni, CTO, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com