Linaro GCC FAQ Page
This is a consolidated list of FAQ's for Linaro GCC.
Where is Linaro Toolchain workgroup page?
What components does the Toolchain Working Group work on?
Our main focus is the following projects. We work directly with upstream communities: GCC, Binutils, GDB, glibc, LLVM, QEMU
What is the relation between GCC Linaro project and mainline (FSF) GCC project?
The Linaro GCC project page is located at https://launchpad.net/gcc-linaro/
As mentioned in above project page, Linaro GCC is performance focused branch of the current GCC stable release and includes backports of the improvements and bug fixes that Linaro and others have done upstream. The project contains backports of work that we and the community have done to improve GCC on ARM.
Also, as Linaro is a not-for-profit company that works with open source, we work towards upstreaming the features we developed on linaro-gcc into mainline GNU GCC project.
What are all the components that go into Linaro Toolchain Binaries in monthly releases?
The toolchain binary releases consist of: (http://releases.linaro.org/<YY.MM>/components/toolchain/binaries)
2014.11 and later releases
- Linux 64-bit binaries for the Aarch64 Linux cross-toolchain
- Windows 32-bit binaries for the Aarch64 Linux cross-toolchain
- Linux 64-bit binaries for the Aarch64 bare-metal cross-toolchain
- Windows 32-bit binaries for the Aarch64 bare-metal cross-toolchain
- Linux 64-bit binaries for the Aarch64 Linux Big Endian cross-toolchain
- Windows 32-bit binaries for the Aarch64 Linux Big Endian cross-toolchain
- Linux 64-bit binaries for the Aarch64 bare-metal Big Endian cross-toolchain
- Windows 32-bit binaries for the Aarch64 bare-metal Big Endian cross-toolchain
- Linux 64-bit binaries for the ARMv7 Linux soft float cross-toolchain
- Windows 32-bit binaries for the ARMv7 Linux soft float cross-toolchain
- Linux 64-bit binaries for the ARMv7 Linux hard float cross-toolchain
- Windows 32-bit binaries for the ARMv7 Linux hard float cross-toolchain
- Linux 64-bit binaries for the ARMv7 bare-metal cross-toolchain
- Windows 32-bit binaries for the ARMv7 bare-metal cross-toolchain
- Linux 64-bit binaries for the ARMv7 Linux Big Endian hard float cross-toolchain
- Windows 32-bit binaries for the ARMv7 Linux Big Endian hard float cross-toolchain
- Linux 64-bit binaries for the ARMv7 bare-metal Big Endian cross-toolchain
- Windows 32-bit binaries for the ARMv7 bare-metal Big Endian cross-toolchain
- crosstool-ng-linaro-*.tar.bz2: Source for the scripts used to build the toolchain binaries
- gcc-linaro-aarch64-linux-gnu-*src.tar.bz2: Source for all Little Endian Aarch64 toolchain components (gcc, binutils, gdb, (e)glibc, newlib, ...)
- gcc-linaro-aarch64_be-linux-gnu-*src.tar.bz2: Source for all Big Endian Aarch64 toolchain components (gcc, binutils, gdb, (e)glibc, newlib, ...)
- gcc-linaro-arm-linux-gnueabihf-*src.tar.bz2: Source for Linux Little Endian ARMv7 toolchain components (gcc, binutils, gdb, (e)glibc, ...)
- gcc-linaro-arm-none-eabi-*src.tar.bz2: Source for bare-metal Little Endian ARMv7 toolchain components (gcc, binutils, gdb, newlib, ...)
- gcc-linaro-armeb-linux-gnueabihf-*src.tar.bz2: Source for all Big Endian ARMv7 toolchain components (gcc, binutils, gdb, (e)glibc, newlib, ...)
- gcc-linaro-aarch64-linux-gnu-*_linux.tar.*: Linux 32-bit binaries for the Aarch64 Linux cross-toolchain
- gcc-linaro-aarch64-none-elf-*_linux.tar.*: Linux 32-bit binaries for the Aarch64 bare-metal cross-toolchain
- gcc-linaro-arm-linux-gnueabihf-*_linux.tar.*: Linux 32-bit binaries for the ARMv7 Linux cross-toolchain
- gcc-linaro-arm-none-eabi-*_linux.tar.*: Linux 32-bit binaries for the ARMv7 bare-metal cross-toolchain
- gcc-linaro-aarch64-linux-gnu-*_win32.*: Windows 32-bit binaries for the Aarch64 Linux cross-toolchain
- gcc-linaro-aarch64-none-elf-*_win32.*: Windows 32-bit binaries for the Aarch64 bare-metal cross-toolchain
- gcc-linaro-arm-linux-gnueabihf-*_win32.*: Windows 32-bit binaries for the ARMv7 Linux cross-toolchain
- gcc-linaro-arm-none-eabi-*_win32.*: Windows 32-bit binaries for the ARMv7 bare-metal cross-toolchain
- gcc-linaro-aarch64-linux-gnu-*_runtime.*: Runtime libraries for Aarch64 Linux
- gcc-linaro-arm-linux-gnueabihf-*_runtime.*: Runtime libraries for ARMv7 Linux
Android cross-toolchain binaries are released separately (link to Android Toolchain question).
Where can I get the source code and build instructions to build Linaro-gcc toolchain binaries?
http://releases.linaro.org/<YY.MM>/components/toolchain/binaries. See above for details.
For build instructions, please go to https://wiki.linaro.org/ABE.
Does Linaro gcc toolchain target glibc or eglibc?
- eglibc is a fork of glibc, but they are mostly inter-changeable.
- eglibc allows you to select which features you want in your C library, and so be able to produce a smaller C library.
- In the past, we based our releases on eglibc-2.19 which is compatible with glibc2.19. Android releases target Bionic (Android’s (incompatible) replacement for (e)glibc) instead.
- We distributed binaries using eglibc because that was what most distributions used for historical reasons, and also because it allowed users to build a more slimmed down C library.
- Due to the end of development of eglibc, we have transitioned to glibc beginning version 2.20.
What is the differences between “arm-none-eabi-” and “arm-linux-gnueabihf”? Can I use “arm-linux-gnueabihf” tool chain in bare-metal environment? How do you know which toolchain binary to use where?
The general form of compiler/linker prefix is as follows:
- A indicates the target (arm for AArch32 little-endian, aarch64 for AArch64 little-endian).
- B indicates the vendor (none or unknown for generic) . Note that this is optional (Eg: not present in arm-linux-gnueabihf)
- C indicates the ABI in use (linux-gnu* for Linux, linux-android* for Android, elf or eabi for ELF based bare-metal).
C has values which seem odd until you understand the history behind it (basically AArch32 used to have a linux-gnu ABI which got changed so needed a new name so we have linux-gnueabi). For AArch32 we have linux-gnueabi and linux-gnueabihf which indicate soft float, and hard float respectively.
The bare-metal ABI will assume a different C library (newlib for example, or even no C library) to the Linux ABI (which assumes glibc). Therefore, the compiler may make different function calls depending on what it believes is available above and beyond the Standard C library.
Also the bare-metal ABI and Linux ABI for the 32-bit Instruction sets make different assumptions about the storage size of enums and wchar_t which you have to be careful of (not a complete list). And the difference between the 32-bit and 64-bit ABIs are also numerous and subtle (the obvious example being pointer sizes).
Where can I get compiler to build for bare-metal (non OS) environment?
Download the Cortex R&M binaries that are produced directly by ARM - https://launchpad.net/gcc-arm-embedded
For 4.7 version that has Cortex-A specific libraries added: https://launchpad.net/gcc-arm-embedded/4.7/4.7-2013-q1-update
For Cortex-A versions 4.8 and above, go to http://releases.linaro.org/<YY.MM>/components/toolchain/binaries
- You can use -O2 or -O3 to build the application to improve on performance of the generated code, and ensure you are using correct
- -mcpu/-mfpu/-mfloat-abi options.
Where can I get compiler to build for Linux environment?
Look for “Linaro Toolchain for Cortex-A”
This is where you will get the latest Linaro GCC toolchain binaries.
Where can I get compiler to build for Android-Linux environment?
https://android-git.linaro.org/gitweb?a=project_list&s=linux-android&btnS=Search shows a list of git repositories containing the latest released toolchain binaries in a way that can be pulled in from the manifest file when building the entire Android OS.
What is the difference between arm-linux-androideabi arm-linux-gnueabi toolchain linux toolchain?
- There are a few differences between the Linux EABI and Android EABI definitions - most notably, Android defines the size of an enum to 32 bits while regular Linux defines it as variable.
- Android does not currently use the hardfloat ABI conventions that have become common in regular Linux.
- Android uses the Gold linker by default while the regular Linux builds default to using the BFD linker (this is for upstream compatibility - Android uses gold while most regular Linux distributions use the BFD linker).
This currently applies to Aarch32 (armv7) only, since Gold hasn’t been ported to Aarch64 yet.
- Flags used to build the compiler itself may be different (to be closer to upstream settings)
I am starting a SoC project. Which version of toolchain should I use? What kind of support can I expect for any toolchain issues?
Linaro supports and works on two versions of GCC at any one time. We support each version for a total of two years. For the first year we actively add new performance improvements to the compiler, but for the second year we only fix bugs.
As of 2014.10 these compilers are Linaro GCC 4.8 (in maintenance mode), and Linaro GCC 4.9 (in active development).
With the 2015.05 release we stopped all work on Linaro GCC 4.8, and moved Linaro GCC 4.9 to maintenance only. Linaro GCC 5.x became the new focus of development.
In 2016.06, 4.9 will be moved out of support, 5.x into maintenance and 6.x to development.
Therefore depending on your project life-cycle and internal requirements for a supported compiler you should choose which release to pick up.
If you are early in your project life-cycle and can therefore update the compiler during the project we would recommend using the active development compiler, but if you are late in your project and want to lock the compiler down and not do any changes we would recommend the maintenance compiler.
If you are working on ARMv8, we would recommend using the 4.9 or 5.x compiler for better Aarch64 support.
Does Linaro GCC toolchain support Cortex-A7 along with NEONv2 & VFPv4?
- Yes, the linaro-toolchain-binaries projects supports cortex-a7 + vfpv4, but this is not their default configuration. You can override defaults while compiling by giving
arm-linux-gnueabihf -mcpu=cortex-a7 -mfloat-abi=hard -mfpu=vfpv4
- If you choose to rebuild the toolchain so that -mcpu=cortex-a7 -mfloat-abi=hard -mfpu=vfpv4 become default values, you can choose to do so.
Also, please note that
- -mcpu=cortex-a7 -mfpu=vfpv4 -mfloat-abi=softfp|hard: Cortex-A7 with FPv4.
-mcpu=cortex-a7 -mfpu=neon-vfpv4 -mfloat-abi=softfp|hard: Cortex-A7 with NEONv2 & FPv4.
are the standard ways of configuring gcc to support Cortex-A7.
Below is more information you may find useful for a better perspective: There are four inter-related command-line options here, and below is what each does - and then summarise for Cortex-A7.
-mcpu=CPU: This specifies the integer-side CPU in use. Note that it doesn't specify whether floating point (VFP) or Advanced SIMD (Neon) is available. If both -mcpu & -march appear on the command-line the one furthest to the right on the command line takes precedence. Passing -mcpu=? to GCC will list all valid CPU options.
-march=ARCH: This specifies the base-architecture in use. Note that again this effectively specifies the integer-side CPU in use, and doesn't specify floating point or Advanced SIMD usage. If both -mcpu & -march appear on the command-line the one furthest to the right on the command line takes precedence. Passing -march=? to GCC will list all valid ARCH options.
-mfpu=FPASEC: This specifies which Floating Point/SIMD/Crypto Extensions are available to be used. This covers whether VFP version, NEON version, and ARMv8-A Crypto extensions are available. Note that if you use this command-line option you also need to specify -mfloat-abi=softfp or -mfloat-abi=hard otherwise you will not see code using VFP/Neon/Crypto instructions. Passing -mfpu=? to GCC will list all valid FPASEC options.
-mfloat-abi=FABI. This specifies how the compiler may use VFP/Neon/Crypto instructions. It has three values:
-mfloat-abi=soft: No VFP/Neon/Crypto instructions are used anywhere even if -mfpu is specified on the command line. -mfloat-abi=softfp: If -mfpu=FPASEC is specified on the command-line as well then use FP/Neon/Crypto instructions within functions, but parameters between functions are still passed using integer registers only. -mfloat-abi=hard: If -mfpu=FPASEC is specified on the command-line as well then use FP/Neon/Crypto instructions within functions, and also use the Floating-point register bank to pass parameters between functions.
So to properly specify a CPU when invoking GCC you should pass three parameters on the command-line:
one of -mcpu & -march
GCC's defaults depend on how it has been built. gcc -v will tell you.
(Note the configuration options are named slightly differently. Linaro builds are configured as follows:
- arm-none-linux-gnueabi: --with-arch=armv7-a --with-fpu=none --with-float=soft
- arm-none-linux-gnueabihf: --with-arch=armv7-a --with-fpu=vfpv3-d16 --with-float=hard
Now onto Cortex-A7: Cortex-A7 is fully supported by GCC. The command-line options for use are:
- -mcpu=cortex-a7 -mfpu=vfpv4 -mfloat-abi=softfp|hard: Cortex-A7 with FPv4.
-mcpu=cortex-a7 -mfpu=neon-vfpv4 -mfloat-abi=softfp|hard: Cortex-A7 with NEONv2 & FPv4.
What is the "ARMv7 runtime" used for?(Eg: gcc-linaro-arm-linux-gnueabihf-4.7-2013.03-20130313_runtime.tar.bz2 in 13.03 release)
- runtime tarball contains set of shared libraries that applications built with the toolchain may need at runtime.
- Eg: libstdc++.so.6* is needed by anything built with the included C++ compiler.
- So, unless you are linking all applications statically, libraries (you need) should be copied to the target device (unless it already has compatible copies of those libraries from elsewhere, Eg: copies that were pre-installed with the OS).
- To determine which libraries you application needs, you can run
- arm-linux-gnueabihf-objdump -x your/application | grep NEEDED
Who uses linaro-gcc toolchain for their products?
- Eventually everyone uses the work we produce from the Toolchain Working Group because we deliver straight to the upstream projects. The advantage of using Linaro GCC is that you get to take advantage of the work in a product a year earlier than would otherwise be the case. (As Linaro GCC 4.8 will contain features which will appear in FSF GCC 4.9). For example, we have the most up-to-date optimized toolchain for Linux on Cortex-A7/A8 series)
- Ubuntu has for several years (from GCC 4.5 or so) shipped with a Linaro GCC based toolchain
- Debian has used Linaro GCC for AArch64 support
- Toshiba, Fujitsu, Sony Mobile have also used linaro-gcc in their products.
- Also, please note that this is not a comprehensive list. Because linaro-gcc is completely open source and available to anyone, no one needs to report it to us that they are using it, they just do.
I tried building an older kernel with the latest Linaro-gcc 4.8 based toolchain. Compilation is successful, but kernel freezes after some time on bootup. Note however that compiling the same kernel with older linaro-gcc-4.7 based binaries does not have this issue. What should I do?
In a good number of cases, features or optimizations done to gcc or related components tend to uncover bugs in the kernel that usually get reported and fixed upstream. For example, the commit ID pointed to in https://bugs.launchpad.net/linaro-toolchain-binaries/+bug/1186218/comments/7 fixes such an issue. Make sure you backport this patch to your kernel.
How do I use Linaro's arm-linux-gnueabihf-gcc from the latest binary toolchain release to build applications for soft float systems, i.e. with -mfloat-abi=soft?
This requires multilib support in the toolchain.
Linaro tracked Ubuntu's release, so prior to 12.05, releases were soft float (soft, softfp) only and does not support multilib, as evidenced by running the command:
$ arm-linux-gnueabi-gcc --print-multi-lib
Beginning 12.05, when Precise switched to hard float, Linaro switched its default toolchain configuration from softfp to hard. The only soft float (multilib) configuration supported is armv4t with option -marm -march=armv4t -mfloat-abi=soft. This is included for use when building projects such as Linux and u-boot for earlier architectures.
Hence, to build an application for soft float, use:
arm-linux-gnueabihf-gcc -marm -march=armv4t -mfloat-abi=soft foo.o -o foo
If this does not work, please try adding "-mno-unaligned-access" to disable unaligned access.
Note that although possibly not fully optimized, applications built with the above configuration can still run on higher version-ed arm platforms, e.g. armv7.
If you need multilib support for other platforms or architectures, you'll have to build your own toolchain.
NOTE: There is currently no multilib support for the 4.8 and newer big endian, 4.9 and newer, and 64-bit builds of the toolchain!
I submitted a bug report but was asked to submit a reduced test case. What can I do?
The C-Reduce tool can help users narrow down bugs. See the C-Reduce site at:
There is even a wiki page on test case reduction that could help as well with some examples.
Where can I download the sources of past Linaro gcc releases?
The Linaro gcc main repository is in svn at https://gcc.gnu.org/svn/gcc. Each release is tagged by creating tags/gcc-linaro-V.V-YYYY.MM. There is also a git repository that mirrors it at https://git.linaro.org/toolchain/gcc.git.
The prebuilt binary release for 2014.11 and onwards look vastly different from previous releases. What's changed?
2014.11 is the first release built with ABE, adding more maintainable code base and automatic testing.
- The binary tarballs have been splitted into 3 parts. As a result, you can install only the parts needed:
- gcc-linaro-*.tar.xz - the compiler and tools
- runtime-linaro-*.tar.xz - runtime libraries needed on the target
- sysroot-linaro-*.tar.xz - sysroot (a set of libraries and headers to develop against)
- Sysroots will use the latest (e)glibc release provided by Linaro engineers in order that users get the latest features and optimizations in the system libraries.
- Eglibc 2.15 compatible sysroots will no longer be released. Users that require Eglibc 2.15 sysroots that need the latest Linaro GCC compiler should use the previous quarterly released sysroot.
- x86 (32-bit) Linux host toolchains are no longer provided. x86_64 (64-bit) Linux host toolchains are provided instead.
- Soft-float targeted toolchains are no longer supported.
For more details, please see the release notes at http://releases.linaro.org/14.11/components/toolchain/binaries.
Why are there only Windows 32-binaries for ARM/AARCH64 cross-toolchains on the release page?
There is currently no plan to support Windows 64-binaries.
Where can I download LLVM releases?
Are toolchain binaries for Max OS X available?
No. We do not build an OS X permutation of the compiler since there is currently no member directive or need for it.
I get files with size 0 when extracting the toolchain binaries for Windows. What should I do?
The archiving utility used for the extraction does not have support for handling symbolic links. Try 7-Zip version 15.14 or higher. It will follow the link and create a copy.
Is the glibc getaddrinfo() stack-based buffer overflow vulnerability (CVE-2015-7547) patched in your binary?
This bug was back-ported to Linaro's 2.21 branch of glibc and 2.19 branch of eglibc, and patched as of the 2016.02 release/respin of both the 5.x and 4.9 version binaries. Note that for eglibc 2.19, Ubuntu's patches were used since they apply cleanly.
4.8 and 4.7 are EOL so the fix will NOT be back-ported for these.
What's with the releases.linaro.org page? Where do I go to find the toolchain version I need?
For Dec 2013 and earlier releases, go to http://releases.linaro.org/archive/YY.MM/components/toolchain/binaries. E.g. http://releases.linaro.org/archive/13.12/components/toolchain/binaries.
For releases between Jan 2014 and Jun 2015, go to http://releases.linaro.org/YY.MM/components/toolchain/binaries. E.g. http://releases.linaro.org/15.05/components/toolchain/binaries.
In Jun 2015, the team that manages releases.linaro.org moved to a http://releases.linaro.org/components/toolchain/binaries/<date-stamped-package> path methodology. E.g. http://releases.linaro.org/components/toolchain/binaries/5.3-2016.02.
Additionally, after GCC 4.9, the upstream versioning convention changed for GCC, from 4.9.x to 5.x, so GCC 5.1, 5.2, and 5.3 are all in the same release series, and you should always upgrade 5.1 or 5.2 to the 5.3 (or later) toolchain.
Which float abi is my ARM binary using?
Run readelf -A <filename> and look under 'File Attributes'. If TAG_FP_arch is missing, then it is -mfloat-abi=soft. If TAG_ABI_VFP_args is VFP registers, then it is -mfloat-abi=hard.
Why do I get a 'libc.so.6: version `GLIBC_2.14` not found' error when using the toolchain?
The host system upon which the cross-compiler will run requires a minimum of glibc 2.14, because of API changes to glibc’s memcpy API. Lower versions are NOT supported! For details, see https://bugs.linaro.org/show_bug.cgi?id=1869.
Last Updated: 2016-3-22
WorkingGroups/ToolChain/FAQ (last modified 2017-03-08 10:03:42)