[oe] [PATCH] cairo: disable native atomic operations, conflicts with libatomics-ops

Denys Dmytriyenko denis at denix.org
Thu Mar 17 22:00:31 UTC 2011


On Thu, Mar 17, 2011 at 02:36:48PM -0700, Khem Raj wrote:
> On Thu, Mar 17, 2011 at 12:17 PM, Denys Dmytriyenko <denis at denix.org> wrote:
> > On Thu, Mar 17, 2011 at 03:12:21PM +0100, Henning Heinold wrote:
> >> Hi,
> >>
> >> I looked deeper into the problem.
> >> Cairo looks first for:
> >>
> >> return __sync_fetch_and_add
> >> __sync_val_compare_and_swap
> >>
> >> and defines it as cairo_cv_atomic_primitives="Intel".
> >>
> >> According to http://gcc.gnu.org/wiki/Atomic
> >> arm and sh3/4 should work too.
> >>
> >> If the configure compile fails
> >> cairo is looking for libatomic-ops
> >> support.
> >
> > Similar to what I observed (if not reversed):
> >
> > * If libatomic-ops is not available (no atomic_ops.h), it chooses/falls back
> > to "Intel" provider (i.e. kernel/gcc), which also works on ARM. It's similar
> > to --disable-atomic
> 
> are you sure that --disable-atomic will still prod for atomics in
> gcc/kernel my guess is it
> will disable atomics for good.

Ah, looking deeper into configure script and resulting config.h from both cases 
reveals the actual differences, so you are correct. Unfortunately, there is no 
way to specify --atomic=intel (or any other one) and it does the automatic 
guesswork selecting one or another. And if libatomic-ops is installed, there 
is no way to override it... So, looks like fixing libatomic-ops is the right 
way. I'll wait for Henning to update the recipe for libatomics-ops, otherwise 
I can submit a patch to define AO_REQUIRE_CAS emulation for the temporary 
solution.

-- 
Denys




More information about the Openembedded-devel mailing list