[BUG] OIIO 2.5.7.0 fails to build on Fedora only on aarch64 about openimageio HOT 27 CLOSED

Same issue for openSUSE Tumbleweed

https://build.opensuse.org/package/live_build_log/graphics/OpenImageIO/openSUSE_Factory_ARM/aarch64

from openimageio.

I will force newer BuildRequires.

from openimageio.

all architectures are passing now for me

from openimageio.

Hi Richard!

/builddir/build/BUILD/OpenImageIO-2.5.7.0/src/include/OpenImageIO/simd.h:4796:32: error: cannot convert ‘int16x8_t’ to ‘OpenImageIO_v2_5::simd::vint4::simd_t’ {aka ‘int32x4_t’} in initialization
 4796 |     simd_t val16 = vcombine_s16(vqmovn_s32(clamped), vdup_n_s16(0));
      |                    ~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      |                                |
      |                                int16x8_t

I'll give you more feedback on Debian later this week (maybe this evening CET) since I'm uploading v2.5.7.0 to Debian experimental prior to the SONAME transition and it'll be built on all release architectures, so even arm64.

from openimageio.

I'll give you more feedback on Debian later this week (maybe this evening CET) since I'm uploading v2.5.7.0 to Debian experimental prior to the SONAME transition and it'll be built on all release architectures, so even arm64.

Here: ARM64 build

Hope this helps somehow.

from openimageio.

Unfortuantely I couldn't find anything that helped. For now I have reverted to 2.5.6.0.

from openimageio.

The original build expired so here's a new link showing the error for 2.5.8.0:
https://kojipkgs.fedoraproject.org//work/tasks/1376/112731376/build.log

from openimageio.

openSUSE package updated to 2.5.8.0. same link as above.

from openimageio.

can we maybe revert the neon part from
in the mean time? d58e4aa3e3f4fb42aa1593ae379

from openimageio.

Thanks for your patience. I will look at this issue today.

from openimageio.

Proposed fix here: #4143

Can you try this patch out on your end before I merge it?

The problem is that even though we now have an ARM based Mac in our CI suite, it looks like the flavor of Apple Clang it uses was perfectly happy to accept the code we had and just understand that it was fine to bitcast between those types, whereas it was rejected on the ARM Linux variants (which we don't have available to test on).

Reading documentation on the intrinsics, I believe I was able to repair it, but won't be sure until you give it a try.

The functions get tested, so I know they were correct execution all along, it's just a question of the compiler being strict about the type casting.

from openimageio.

package with the patch is building here: https://build.opensuse.org/package/show/home:darix:branches:graphics/OpenImageIO

you can find multiple distributions and architectures there.

it seems 2.5.8.0 broke the testsuite for us. even updating the images to the latest version does not help.

for the record 2.5.7.0 still passed https://build.opensuse.org/package/show/openSUSE:Factory/OpenImageIO

from openimageio.

If I understand the failing aarch64 logs for the build in progress that you point to above, I believe that it is failing because the Imath/OpenEXR you have installed is 2.2, whereas OpenImageIO 2.5 requires a minimum OpenEXR 2.4. (Current OpenEXR is 3.2, so we're talking about extraordinarily old.)

At least in that log, it's not getting anywhere near far enough in the build for the NEON patch to be relevant. It fails just trying to find dependencies.

from openimageio.

For reference, OpenEXR 2.4 was released in 2019.

from openimageio.

@hobbes1069 Your error was definitely on the NEON part. Please do let me know (if you can check) whether the patch from this PR gets you unstuck.

from openimageio.

@lgritz yes, seems to be all good now, just built 2.5.7.0.
https://kojipkgs.fedoraproject.org//work/tasks/6094/113136094/build.log

from openimageio.

Outstanding, thanks @hobbes1069. Would you mind please clicking approve on #4143, since basically fixing your build break is the whole reason for that patch? Thanks.

from openimageio.

@lgritz got any ideas about the new testsuite failures on x86_64 https://build.opensuse.org/package/live_build_log/home:darix:branches:graphics/OpenImageIO/openSUSE_Tumbleweed/x86_64 ?

from openimageio.

@darix Those look suspiciously like the same failures as here https://github.com/AcademySoftwareFoundation/OpenImageIO/actions/runs/7811654989/job/21307148511
which is our "bleeding edge" in which we test against the top-of-tree of several dependencies. The current (unreleased) top commit in openexr appears to be responsible for that failure, and it's a bug the openexr team is trying to fix before they make their release.

Are you by any chance using an exr that's either taken right from their master, or incorporates that broken patch from the top of their master?

from openimageio.

https://build.opensuse.org/package/show/graphics/openexr

from openimageio.

Yes, that openexr-CVE-2023-5841.patch is the one with the bug, as far as I can tell.

from openimageio.

oki. will keep that in mind.

from openimageio.

Sigh. CVEs.

As I understand it, this CVE was addressing a potential memory clobber in a utility that is only used for OpenEXR's own testing. It not an exploitable problem in any application that uses openexr because it's not in code that any real app would call.

But because everybody drops everything when the magic word "CVE" is uttered, lest an unaddressed CVE be a stain on the project and jeopardize its inclusion in distros, the "fixes" are rushed out without proper care or time to test. This is yet another instance of a CVE that reports something that isn't really a problem and the rush to fix caused a much worse one.

(The situation was also compounded by an unrelated logistical problem, wherein the openexr team did not receive the email that reported the bug and only found out about the problem when the CVE was published, which was done without anybody checking in with the project authors to verify that we received the email or ask why we hadn't responded.)

from openimageio.

I brought up the state of the openexr patch to the suse security team so we can remedy the situation. :)

now that we have a fix for OpenImageIO ... it is back to the coal mines and trying to hammer the cmake mess for MaterialX/OpenUSD into shape that one can finally install it properly.

Thank you for your support and keep up the great work! :)

from openimageio.

So sorry about the openexr issue. We are working hard to try to fix it ASAP. We held up our release while we work it out, not realizing that the bad commit had been cherry picked into your patches.

from openimageio.

honestly compared to MaterialX/OpenUSD this is harmless :)

from openimageio.

Fixed via #4143.

from openimageio.