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=9e5bf767ccb275d85417dd6a04590276941d3934
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
--
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
http://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
