mirror of https://github.com/acidanthera/audk.git
41203b9ab5
The 'arm-linux-gnueabihf' target triplet we use for CLANG35 and CLANG38 specifies a hardfloat target, and so the binaries that are emitted are annotated as using VFP registers for passing floating point arguments, even though no VFP is used anywhere in the code. This works fine as long as we don't try to link against code that uses software floating point, but combining object files with different floating point calling conventions is not permitted. So switch to the softfloat arm-linux-gnueabi triplet instead. This affects both the name Clang uses when invoking the linker, and the arguments it passes to it, and we are mostly interested in the latter (since any version of GNU ld.bfd will do the right thing as long as it targets EABI ARM) For native builds, this change has no effect, since the unprefixed system linker will take priority, and so Clang will pass the right arguments to whichever linker happens to be the system linker. For cross builds, the fact that Clang composes the name of the linker by prefixing '-ld' with the target triplet implies that users will have to switch to a version of binutils that targets arm-linux-gnueabi rather than arm-linux-gnueabihf. Note that the GCCx toolchain targets can use either when building for ARM so this does not create a need to install two versions of the ARM cross toolchain. Also, note that all ARM toolchains in the GCC family are already documented as requiring a toolchain that targets arm-linux-gnueabi and not arm-linux-gnueabihf. Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Liming Gao <liming.gao@intel.com> Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org> |
||
---|---|---|
.. | ||
XMLSchema | ||
Empty_Package_Information_Data_File.ini | ||
FrameworkDatabase.template | ||
ReadMe.txt | ||
build_rule.template | ||
target.template | ||
tools_def.template |
ReadMe.txt
This directory contains the template files for the next generation of the EDK II Build infrastructure. These files will be copied into the WORKSPACE's Conf directory if and only if the target files do not exist. These files may be updated frequently. The XMLSchema directory contains the EDK II Packaging XML definitions. The schema may change in the future. It differs somewhat from the early versions of the XML Schema.