From: "Khem Raj" <raj.khem@gmail.com>
To: Andrea Adami <andrea.adami@gmail.com>
Cc: Patches and discussions about the oe-core layer
<openembedded-core@lists.openembedded.org>
Subject: Re: [OE-core] RFC: pulseaudio vs. meson vs. neon
Date: Mon, 28 Jun 2021 11:46:08 -0700 [thread overview]
Message-ID: <6e2bcb94-8b02-50c1-bf5b-8fc3ce464d91@gmail.com> (raw)
In-Reply-To: <CAAQYJAsGX9ExxsmoGUY8wO_Bp_JscSoRJ-pBiNJ4oBf5eBf5CQ@mail.gmail.com>
On 6/28/21 11:20 AM, Andrea Adami wrote:
> On Mon, Jun 28, 2021 at 7:55 PM Khem Raj <raj.khem@gmail.com> wrote:
>>
>> Hi Andrea
>>
>> On 6/28/21 3:01 AM, Andrea Adami wrote:
>>> Hello,
>>>
>>> during a core-image-sato build for armv4 I got one single build
>>> failure with pulseaudio.
>>>
>>> This happens after commit 80bbea0 pulseaudio: switch build system from
>>> Autotools to Meson. In the commit text it is evidenced:
>>>
>>> "
>>> With Meson there's no option for disabling Neon optimizations if the
>>> compiler supports Neon. If -mfpu is set in CC or CFLAGS, it's ignored,
>>> because the build system adds -mfpu=neon at the end of the compiler
>>> command line, overriding any earlier -mfpu options. This shouldn't be
>>> a problem, because PulseAudio detects at runtime whether the CPU
>>> supports Neon instructions.
>>> "
>>>
>>> At the moment to build pulseaudio for armv4/5 I have reverted to using
>>> autotools.
>>>
>>>
>>> There was around a patch but has not been merged.
>>> https://lists.openembedded.org/g/openembedded-core/message/146375
>>>
>>
>> this patch is not right. It might let us compile but it will still emit
>> code that will expect VFP at runtime and hence fail to run.
>>
>>> Maybe a v2 will be accepted?
>>
>> right fix would be to add a proper neon support check in pulseaudio
>> meson'ary, and if PA has dropped the ball on non VFP ARM then it will be
>> hard to convince upstream to accept it but atleast you can try.
>>
>
> Thank you for the review.
> I knew the patch was not right, I tried other workarounds and I
> failed. That's why the RFC was sent.
>
> With my very limited knowledge about the matter it would be impossible
> for me to argue with L.P. upstream.
> My personal opinion is that the switch to meson was done too early, at
> least 14.x could have used autotools and less meson patches.
>
> But if upstream deliberately breaks compatibility there isn't much we
> can do, maybe overpatching. sigh...
>
I still hope that if we can add a proper neon detection patch to meson
they would be ok to accept it.
> Cheers
> A.A.
>>>
>>> Cheers
>>> A.A.
>>>
>>>
>>>
>>>
>>>
next prev parent reply other threads:[~2021-06-28 18:46 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-28 10:01 RFC: pulseaudio vs. meson vs. neon Andrea Adami
2021-06-28 10:59 ` [OE-core] " Alexander Kanavin
2021-06-28 12:08 ` Andrea Adami
2021-06-28 12:36 ` Alexander Kanavin
2021-06-28 12:44 ` Andrea Adami
2021-06-28 13:03 ` Richard Purdie
2021-06-28 13:10 ` Andrea Adami
2021-06-28 17:55 ` Khem Raj
2021-06-28 18:20 ` Andrea Adami
2021-06-28 18:46 ` Khem Raj [this message]
2021-06-28 19:10 ` Phil Blundell
2021-06-28 19:42 ` Khem Raj
2021-06-28 19:52 ` Phil Blundell
2021-06-28 21:10 ` Khem Raj
2021-06-28 21:21 ` Phil Blundell
2021-06-28 21:40 ` Khem Raj
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=6e2bcb94-8b02-50c1-bf5b-8fc3ce464d91@gmail.com \
--to=raj.khem@gmail.com \
--cc=andrea.adami@gmail.com \
--cc=openembedded-core@lists.openembedded.org \
/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