Hi,
On 26-02-16 11:51, Peter Robinson wrote:
Peter Robinson wrote:
It's an issue we see occasionally where the package thinks it knows better than the explicit CFLAGs being set, I'll get it sorted out.
But why are those intrinsics now requiring NEON at all? Those are GCC byte swap intrinsics documented as being architecture-independent and should be implemented in software (through shifts or rotates) when there is no native byte swap instruction.
And is Fedora actually requiring NEON as the baseline on ARM? I thought it was not.
We require an ARMv7A or newer and a VFP with enough registers to support the hard ABI e.g. -march=armv7-a -mfloat-abi=hard -mfpu=vfpv3-d16
Correct, there is no requirement for NEON, it's optional in the ARMv7 spec. Some code looks at the HW and tries incorrectly to enable NEON optimisation, this is incorrect code, it should be obeying the CFLAGS passed by the compiler and if it wishes to support NEON do so with fast paths in the code (see libpng/pixman/cairo for examples). This isn't new to gcc6, we've seen it on and off ever since I've been dealing with ARM architectures all the way back to (at least) gcc 4.3
Right I've recently fixed the same build-error in openal-soft, see:
http://pkgs.fedoraproject.org/cgit/rpms/openal-soft.git/commit/?id=9e5bf767c...
Specifically what I had to do was:
-%cmake . +%cmake -DALSOFT_CPUEXT_NEON:BOOL=OFF .
IOW I turned of the unconditional use of NEON in the code. Now with mozjs chances are it does runtime detection and only uses the code in the object file which tries to build when it runtime detects NEON, if that is the case then the ideal solution would be to change the buildsys to pass -ffpu=neon (IIRC) when building that specific object-file.
If you're unsure what to do the best thing is to just disable the use of neon altogether like I did with openal-soft.
Regards,
Hans