<html>
  <head>
    <meta content="text/html; charset=windows-1252"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 08/29/2014 06:28 AM, Yi Qingliang
      wrote:<br>
    </div>
    <blockquote
cite="mid:CADwFkYeYJVe0KyVY3gipy-cGm4kRhaHoit2WThcKsLnpdyyrOw@mail.gmail.com"
      type="cite">
      <div dir="ltr">hardware: samsung s3c6410<br>
        <br>
        after updated to latest poky, the boost compile fail!<br>
        <br>
        error info:
        <div>
          <div>libs/atomic/src/lockpool.cpp:127:5: error: 'thread_fence'
            is not a member of 'boost::atomics::detail'<br>
          </div>
          <div>libs/atomic/src/lockpool.cpp:138:5: error: 'signal_fence'
            is not a member of 'boost::atomics::detail'</div>
        </div>
        <div><br>
        </div>
        <div><br>
        </div>
        <div>after dig into it, I found that:</div>
        <div>the marco 'BOOST_ATOMIC_FLAG_LOCK_FREE' is 0, so it don't
          include 'operations_lockfree.hpp' which has 'thread_fence' and
          'signal_fence', but pthread.h at line 21.<br>
          <br>
        </div>
        <div>in file 'caps_gcc_atomic.hpp',
          'BOOST_ATOMIC_FLAG_LOCK_FREE' is set to '0', the author think
          if '__GCC_ATOMIC_BOOL_LOCK_FREE' is 1, the atomic serial
          function gcc provided is not lock free.</div>
      </div>
    </blockquote>
    <br>
    This is the sort of GCC internal header indicator that would have
    changed value as a result of:<br>
    <br>
<a class="moz-txt-link-freetext" href="http://cgit.openembedded.org/openembedded-core/commit/meta/recipes-devtools/gcc/gcc-configure-common.inc?id=0ba6ab39f187ecd4261f08e768f365f461384a3a">http://cgit.openembedded.org/openembedded-core/commit/meta/recipes-devtools/gcc/gcc-configure-common.inc?id=0ba6ab39f187ecd4261f08e768f365f461384a3a</a><br>
    <br>
    <blockquote
cite="mid:CADwFkYeYJVe0KyVY3gipy-cGm4kRhaHoit2WThcKsLnpdyyrOw@mail.gmail.com"
      type="cite">
      <div dir="ltr"><br>
        <div>at the end of 'caps_gcc_atomic.hpp', it defined
          'BOOST_ATOMIC_THREAD_FENCE' as 2.</div>
        <div><br>
        </div>
        <div>so the conflict is: <b>BOOST_ATOMIC_THREAD_FENCE</b> and <b>BOOST_ATOMIC_FLAG_LOCK_FREE</b></div>
        <div><b><br>
          </b></div>
        <div>I don't know it is the new poky problem, or the boost
          problem, any idea?</div>
      </div>
    </blockquote>
    <br>
    My guess is that Boost is making assumptions about what the internal
    GCC predefined symbols mean that aren't entirely accurate.  There
    are several flags that are used in the libstdc++ headers to indicate
    whether the compiler is using lock-free instructions.<br>
    <br>
    Boost-1.56 builds without error for my beaglebone target with poky
    at:<br>
    <br>
    * 669c07d (HEAD, origin/master, origin/HEAD, master/upstream,
    master/dev) [Wed Aug 27 14:24:52 2014 +0100] bitbake: build/data:
    Write out more complete python run files<br>
    <br>
    so it may have something to do with your target machine.<br>
    <br>
    Peter<br>
  </body>
</html>