This repository has been archived by the owner on Dec 20, 2024. It is now read-only.
arm compiler has no VFP or NEON in default flags #8
Comments
ramcq
added a commit
to ramcq/libreoffice-flatpak
that referenced
this issue
Sep 6, 2017
This reverts commit 743ec50. The part of the LO buildsystem which I was trying to fix happens to not repect CFLAGS. However, the bug is actually more serious - the ARM compiler in the freedesktop.org SDK has no FPU settings - neither VFP nor NEON. I've filed flatpak/freedesktop-sdk-base#8 to track that.
ramcq
added a commit
to ramcq/freedesktop-sdk-base
that referenced
this issue
Sep 28, 2017
The way that Yocto works when compiling is to build "default" compilers for the target architecture, then to apply the "tunes" (FPU settings, SIMD extensions, etc) by replacing $CC with a very long invocation that includes all of the stuff you set up in your machine/architecture recipes. Unfortunately this means that if you ask Yocto to build a compiler for you, and then take it outside of the Yocto build environment, the compiler doesn't inherently default to any of the same tunes which were used at the time of building the platform/SDK. On ARM this is particularly bad because it means the Flatpak SDK has effectively been building binaries with a different ABI to the platform, including soft rather than hard float, no VFP, no thumb, etc. This has caused build failures as pretty much everyone (whether armel or armhf) assumes VFP is available, and is very likely to cause app crashes at runtime in apps that use floating point due to not preserving the right registers in the calling convention. For our ARM v7 platform, manually set the configure options for gcc so that the selected/intended ABI/tunes are set for the compiler inside the SDK, rather than only at the time we compile the SDK itself. (This is an instance of https://bugzilla.yoctoproject.org/show_bug.cgi?id=139 upstream in Yocto - also known as "nobody who uses Yocto uses the compiler inside the image".) flatpak#8
alexlarsson
pushed a commit
that referenced
this issue
Sep 28, 2017
The way that Yocto works when compiling is to build "default" compilers for the target architecture, then to apply the "tunes" (FPU settings, SIMD extensions, etc) by replacing $CC with a very long invocation that includes all of the stuff you set up in your machine/architecture recipes. Unfortunately this means that if you ask Yocto to build a compiler for you, and then take it outside of the Yocto build environment, the compiler doesn't inherently default to any of the same tunes which were used at the time of building the platform/SDK. On ARM this is particularly bad because it means the Flatpak SDK has effectively been building binaries with a different ABI to the platform, including soft rather than hard float, no VFP, no thumb, etc. This has caused build failures as pretty much everyone (whether armel or armhf) assumes VFP is available, and is very likely to cause app crashes at runtime in apps that use floating point due to not preserving the right registers in the calling convention. For our ARM v7 platform, manually set the configure options for gcc so that the selected/intended ABI/tunes are set for the compiler inside the SDK, rather than only at the time we compile the SDK itself. (This is an instance of https://bugzilla.yoctoproject.org/show_bug.cgi?id=139 upstream in Yocto - also known as "nobody who uses Yocto uses the compiler inside the image".) #8
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
It seems that due to https://bugzilla.yoctoproject.org/show_bug.cgi?id=139 and the fact that we use the Yocto "target" GCC instead of the "SDK" GCC, our setting of armv7a-neon (specifically the fact that this tunes the FPU to NEON which also enables VFP3) is not being passed on to the gcc inside the SDK. This caused a build failure in LibreOffice in a place where VFP3 was being assumed, but will across the board cause poor performance on 32-bit ARM systems. Once we've fixed it, we will need to rebuild all of our SDKs and ARM flatpaks. Incidentally changing this should also correctly bubble up the default availability of NEON, which I believe was messing up WebKit builds on ARM.
The text was updated successfully, but these errors were encountered: