On 2025-04-16 2:41 p.m., Jeremie Courreges-Anglas wrote:
> On Sun, Mar 30, 2025 at 02:09:48AM -0400, Brad Smith wrote:
>> On 2025-03-29 8:25 a.m., Jeremie Courreges-Anglas wrote:
>>> On Fri, Mar 28, 2025 at 07:24:07PM -0400, Brad Smith wrote:
>>>> ping.
>>>>
>>>> On 2025-03-09 5:59 p.m., Brad Smith wrote:
>>>>> I have not run this through a build yet but I believe this is what is necessary.
>>>>>
>>>>> I was wondering why a projects compiler checks were failing for SVE but the
>>>>> commit message gave me a clue and sure enough our local build bits were
>>>>> missing installing the header once we jumped past the 14 release. Copying
>>>>> the header from the port resolved the issue.
>>> Using codesearch.debian.net I found the following users:
>>>
>>> multimedia/aom
>>> multimedia/libvpx
>>> multimedia/svt-av1
>>> multimedia/x265
>>>
>>> and a bunch of embedded copies of these, mainly in chromium and
>>> firefox.  libvpx and x265 build, aom shows some warnings at build
>>> time, and svt-av1 fails to build:
>>>
>>> https://wxcvbn.org/~jca/tmp/aom.log
>>> https://wxcvbn.org/~jca/tmp/svt-av1.log
>>>
>>> Tested on an m2 with the missing header installed.
>> I just ran into the issue with SVT-AV1updating it to to 3.0.x thinking it
>> was an issue with the newer releases but as you pointed out its already an
>> issue with 2.3.0. I am going to disable the SVE support for now. I had also
>> ran into this issue and tested the SVE support in my VVenC port. As well as
>> x265, aom and libvpx.
> FWIW I retried multimedia/aom on my arm64 machine, using a wip
> clang-19 update from robert@, and the aom warning became a fatal error:
>
>    fatal error: error in backend: Invalid size request on a scalable vector.
>    cc: error: clang frontend command failed with exit code 70 (use -v to see invocation)
>
> Have you tried to investigate the warnings seen earlier with clang-16?
>
>    warning: Invalid size request on a scalable vector; Cannot implicitly convert a scalable size to a fixed-width size in `TypeSize::operator ScalarTy()`

I was not aware of the change between 16 and 19. All of my testing had 
been with
16 so far.

I built and tested 20 and main and they build all of the ports without 
issue.

A bisect was done and the commit found that fixed this issue. All of the 
ports
build fine with either 16 or 19 with the patch applied that I sent to 
ports. Which
can be applied to base too.