Peter Robinson wrote on Tue, Aug 04, 2020: > > The "fix" here is simple and upstream is reactive so I'll just resubmit > > the package with -mfpu=neon appended to linker args as well, but this > > might come bite other projects as well. > > NO! That is not the fix. We explicitly don't build with NEON on armhfp > because there are ARMv7 processors that don't have NEON and that would > then crash on those devices. Hm, yes and no - it is a bug in waypipe as you've said below, but we already were building the neon object before and what broke the build is LTO. So, sure, I can also work towards disabling neon optimisations instead; the meson file doesn't provide an option for that but it's not too difficult. Note there is the same problem with avx, it builds with avx512f if the compiler supports it -- I think it's fairly standard for upstreams to just enable everything by default if it's available, and we need to turn it off. I'm not sure what the standard way is to do that with meson, will have to do some zoology first... neon and avx instructions are pretty mainstream for streaming (waypipe is a kind of vnc) so I expect other packages have fixed similar problems in the past... > On aarch64/ARMv8 it can be assumed there's NEON because it's a > required part of the standard, but it's not a requirement for ARMv7 > processors so the software should do run time detection / fast path > code to optimise if it detects NEON at runtime NOT compile time. waypipe is actually one of the better projects in the regard that there are tests run in the %check section (thanks to whoever made the initial package I took over), and the tests run fine with NEON enabled on arm. Would it be possible to have hardware we're actually supposed to support available for rpm checks? I think it's precisely why we have checks ; this package has been broken for platforms without neon ever since it had been introduced. It's also probably broken on machines without avx512. I don't have access to any such machine where I could do this kind of tests, and I'm not the original packager of this thing, so don't expect me to know how to deal with that. > > I don't think gcc can intuite this so it's probably not a bug though > > (hence I'm not planning on opening a bug), but it is a regression of > > sort... > > You're wrong. I would appreciate slightly less conflicting exchanges in the future; I'm happy to do things differently if I'm pointed at problems but there *is* a change of behaviour with LTO and that isn't wrong. I apprently proceeded to fix it in a way that's not appropriate for fedora, but this is this and that is that, no need to shout. Thanks, -- Dominique _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
