From: Phil Blundell <pb@pbcl.net>
To: Khem Raj <raj.khem@gmail.com>
Cc: Patches and discussions about the oe-core layer
<openembedded-core@lists.openembedded.org>
Subject: Re: [PATCH 8/8] boost: Fix build on soft-float ABI arm systems
Date: Wed, 03 Feb 2016 21:24:51 +0000 [thread overview]
Message-ID: <1454534691.7421.71.camel@pbcl.net> (raw)
In-Reply-To: <CAMKF1so4wbS=T6rF-uS5SmgSAA9_QmxtVLm97-mvTKb938p+Dg@mail.gmail.com>
On Wed, 2016-02-03 at 12:58 -0800, Khem Raj wrote:
> On Wed, Feb 3, 2016 at 12:42 PM, Phil Blundell <pb@pbcl.net> wrote:
> I think it might be true
> > that some libraries don't implement fesetenv() when using softfp (i.e.
> > no VFP instructions at all) but that is not necessarily the same thing
> > as the soft float ABI.
>
> does glibc implement it correctly using soft-fp ? my tests failed for
> glibc thats why
> I used the VFP detection logic
It depends what you mean by "correctly". If you don't have a VFP unit
then fesetenv() will fail (return nonzero) but the symbols will be
available and there should be no error at build time. If you do have a
VFP unit and are using it then, irrespective of your ABI, fesetenv()
should succeed and subsequent operations ought to behave correctly.
I think there is a possible hole in the case where you do have a VFP
unit available but have compiled your code -msoft-float, have not
installed a VFP optimized library, and hence are not actually using the
VFP. In this situation, yes, I think it's quite conceivable that glibc
might be doing the wrong thing. Fortunately I think this scenario is
rare enough that we probably don't need to worry about it too much.
p.
prev parent reply other threads:[~2016-02-03 21:24 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-01 5:08 [PATCH 0/8] Musl related and misc fixes Khem Raj
2016-02-01 5:08 ` [PATCH 1/8] libnss-mdns: Check for nss.h before using Khem Raj
2016-02-01 5:08 ` [PATCH 2/8] nss-myhostname: Fix build on musl Khem Raj
2016-02-01 21:13 ` Burton, Ross
2016-02-01 22:29 ` Khem Raj
2016-02-01 5:08 ` [PATCH 3/8] distutils: Consider S != B case Khem Raj
2016-02-01 18:02 ` Richard Purdie
2016-02-01 18:23 ` Khem Raj
2016-02-01 5:08 ` [PATCH 4/8] pth: Remove dead code Khem Raj
2016-02-01 10:23 ` Burton, Ross
2016-02-01 12:33 ` Burton, Ross
2016-02-01 17:09 ` Khem Raj
2016-02-01 5:08 ` [PATCH 5/8] libtool-cross: Unset pre|post dep objects Khem Raj
2016-02-01 17:29 ` Khem Raj
2016-02-01 5:08 ` [PATCH 6/8] db: Use cross libtool Khem Raj
2016-02-01 5:08 ` [PATCH 7/8] local.conf.sample.extended: Document HOW-TO enable systemd or busbox for init system Khem Raj
2016-02-01 5:08 ` [PATCH 8/8] boost: Fix build on soft-float ABI arm systems Khem Raj
2016-02-03 20:42 ` Phil Blundell
2016-02-03 20:58 ` Khem Raj
2016-02-03 21:24 ` Phil Blundell [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=1454534691.7421.71.camel@pbcl.net \
--to=pb@pbcl.net \
--cc=openembedded-core@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox