[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