Buildroot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
To: buildroot@busybox.net
Subject: [Buildroot] [PATCH 1/1] cc-tool: depends on BR2_TOOLCHAIN_HAS_SYNC_4
Date: Tue, 5 Jun 2018 22:07:02 +0200	[thread overview]
Message-ID: <20180605220702.303ee975@windsurf> (raw)
In-Reply-To: <20180605181514.2081-1-fontaine.fabrice@gmail.com>

Hello Fabrice,

On Tue,  5 Jun 2018 20:15:14 +0200, Fabrice Fontaine wrote:
> 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
> 
> Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>

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

      reply	other threads:[~2018-06-05 20:07 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-06-05 18:15 [Buildroot] [PATCH 1/1] cc-tool: depends on BR2_TOOLCHAIN_HAS_SYNC_4 Fabrice Fontaine
2018-06-05 20:07 ` Thomas Petazzoni [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20180605220702.303ee975@windsurf \
    --to=thomas.petazzoni@bootlin.com \
    --cc=buildroot@busybox.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox