From: Denys Dmytriyenko <denis@denix.org>
To: Khem Raj <raj.khem@gmail.com>
Cc: openembedded-devel@lists.openembedded.org
Subject: Re: [PATCH] cairo: disable native atomic operations, conflicts with libatomics-ops
Date: Thu, 17 Mar 2011 18:00:31 -0400 [thread overview]
Message-ID: <20110317220031.GP3042@denix.org> (raw)
In-Reply-To: <AANLkTimAMd88wthcF_fqG5+9rE1UjLmayMPFco7xhS2d@mail.gmail.com>
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@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
next prev parent reply other threads:[~2011-03-17 22:02 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-17 1:25 [PATCH] cairo: disable native atomic operations, conflicts with libatomics-ops Denys Dmytriyenko
2011-03-17 1:43 ` Denys Dmytriyenko
2011-03-17 3:25 ` Khem Raj
2011-03-17 7:37 ` Koen Kooi
2011-03-17 8:51 ` Henning Heinold
2011-03-17 14:12 ` Henning Heinold
2011-03-17 14:47 ` Koen Kooi
2011-03-17 17:18 ` Henning Heinold
2011-03-17 19:17 ` Denys Dmytriyenko
2011-03-17 21:36 ` Khem Raj
2011-03-17 22:00 ` Denys Dmytriyenko [this message]
2011-03-18 7:02 ` Esben Haabendal
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=20110317220031.GP3042@denix.org \
--to=denis@denix.org \
--cc=openembedded-devel@lists.openembedded.org \
--cc=raj.khem@gmail.com \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.