5.1. Frequently Asked Questions

Where can I find further information?

The recommended starting point for further information is the CodeSourcery toolchain FAQ at: http://www.codesourcery.com/gnu_toolchains/arm/faq.html

You may also wish to look at ARM and Linux forums and newsgroups, or looking at mailing list archives. http://www.arm.linux.org.uk/ provides resources relating specifically to ARM Embedded Linux.

Note that ARM does not provide support on the use of the GNU tools. See section 1.1 for details.

How do I build an EABI-compliant Linux kernel?

Prior to version 2.6.16 there is no such thing as an EABI-compliant kernel. This is due to the large amount of assembly code in the kernel that would require significant time and effort to rewrite. However, this is not important as the EABI-compliant GNU C library translates calls appropriately from EABI-compliant applications to the non-EABI compliant kernel system calls.

From kernel version 2.6.16, it is possible to build an EABI kernel. However, this is only an issue for applications and libraries which directly access kernel structures or functions.

Which kernel version should I use?

The CodeSourcery toolchain as provided in binary form is built to use NPTL (Native POSIX Thread Library) and it expects to have TLS (thread-local storage) support in the kernel. According to CodeSourcery, the glibc initialization code requires kernel version 2.6.16 or later. Alternatively, your Linux distributor may have already applied the appropriate patches to their kernel build. You should contact your Linux distributor for more information.

Why do you need to pass so many options to the compiler?

The ARM compiler and linker are primarily used to create standalone, bare-metal applications. The options described in section 2 and shown in the example makefiles make necessary changes to the application image, for correct operation in an ARM Linux environment.

Can you use EABI-compliant and non-EABI-compliant applications together?

Yes. You should place the libraries and the dynamic linker in a different directory to the normal libraries. We recommend that you use /libeabi for the EABI-compliant libraries, and leave the original, non-EABI compliant libraries in /lib.

You must then set the library search path for EABI applications using the environment variable LD_LIBRARY_PATH=/libeabi or by using the ‑‑rpath linker option. We recommend that you rebuild all applications to use the EABI in your final system as the extra libraries take up a significant amount of space in the file system.

The compiler generates errors like "Identifier va_list is undefined" when building GNU-style code.

This is because of slightly differing methods of implementing variadic functions between RVCT and GCC. The solution is to use the compiler option ‑‑preinclude stdarg.h to include the definitions of these types before the start of the application code.

I receive warning "L6765W: Shared object entry point must be ARM state with v4T"

The GNU C library startup code does not contain all of the build attributes that the linker uses to determine its execution state. As a result the linker is unable to confirm that the entry point is in ARM code. As the GNU C library startup code is ARM code, you can safely ignore this warning, or suppress this as in the examples with ‑‑diag_suppress 6765.

The GNU tools report "ERROR: Source object … has EABI version 5, but target … has EABI version 4" when used on objects generated by RVCT 3.0

RVCT 3.0 generates ELF files conforming to the latest revision of the ABI. Specifically, they implement revision 5 of the AAELF (ARM ABI ELF) specification. However, CodeSourcery's 2005-Q3-2 release only supports revision 4 of the AAELF specification and will not consume objects produced by RVCT 3.0 tools. Support for the new ABI revision is included in the 2006-Q1-3 and later releases of the CodeSourcery toolchain.

armlink reports "Fatal error: L6033U: Symbol in crt1.o is defined relative to an invalid section."

In the 2006-Q1-3 release of the CodeSourcery toolchain the crt1.o object file has not been correctly stripped. The supplied example scripts ensure that crt1.o object is correctly stripped before linking. This has been fixed in the 2006-Q1-6 CodeSourcery release. Alternatively you can strip the crt1.o object yourself.

Intermixing RVCT hardware VFP objects and GNU libraries

The GNU libraries as CodeSourcery supply in their ready-built binary packages are not built with hardware VFP support and return their results in the ARM core's registers. However RVCT object files that are built for hardware VFP will expect the result to be returned in the VFP co-processor registers and not in the ARM core's registers.

The recommended solution is compile with ‑‑fpu SoftVFP+VFP. However, you can also workaround this by adding #pragma softfp_linkage before your list of #include lines, and #pragma no_softfp_linkage afterwards. For example:

#pragma softfp_linkage
#include <stdlib.h>
#pragma no_softfp_linkage

This will instruct armcc to expect the results to be placed in the ARM core's registers when calling these library functions. However you will not get the full benefit of the hardware VFP.

In a large application armlink reports "L6016U: Symbol table missing/corrupt in object/library <object>."

This is because the GNU ar command can generate incompatible information. Replace ar with armar and use the same command line arguments. Alternatively, the error is recoverable by using "armar -s" to rebuild the symbol table.

Common problems with running your application

Some common problems with running your application are described in Table 7.

Table 7. Common problems with running applications

Cannot find the application
  • Check that you have set the executable flag for the program (use chmod +x program)

  • Check that the application is on the path, or you are running it with ./program in the current directory

  • The dynamic loader may not be the same as specified at link time. In this case, use /path-to-linker/dynamic-loader program-path/programFor example:

    /libeabi/ld-linux.so.3 /opt/bin/eabi/hello
"GLIBC_2.4 not found" error"unable to find library XXX.so.X"

This is the dynamic linker reporting that it cannot use the libraries found on its default path. You can use the LD_LIBRARY_PATH environment variable to access the correct libraries. For example:

LD_LIBRARY_PATH=/libeabi ./helloworld

Alternatively you can use the ‑‑rpath linker option.

"Illegal instruction" error before main()

This indicates that the image has been built for the incorrect architecture (e.g. v6 code running on a v5TE core), or the kernel has not been built with NPTL support.

Check that you have built the image for the correct ARM architecture and check that you are using either a 2.6.12 (or later) Linux kernel or one with the appropriate patches applied as part of your distribution.

Once at main this is likely to be an actual undefined instruction in the application.

Various Dynamic linker errors

The pre-built libraries supplied in the 2006-Q1-3 release of the CodeSourcery toolchain are built with an ABI tag that require Linux kernel 2.6.16 or later. The dynamic linker will generate various error messages when run on older kernel revisions. To avoid this you will need to update to the 2.6.16 or later kernel or rebuild the libraries to support an older kernel revision.

Segmentation faults

There are a variety of possible causes of segmentation faults. They may be caused by problems with your application. You should also ensure that:

  • You have linked against the GNU C library and used the ‑‑no_scanlib linker switch. Even for a dynamic library, if you do not link against glibc, armlink may statically link the semihosted I/O functions from the RVCT libraries into your application or dynamic library

  • When creating a dynamic library, you have compiled and linked as position-independent code (use ‑‑apcs /fpic for the compiler and ‑‑fpic for the linker)

  • When creating an application, you have used the linker switches ‑‑nostartup and ‑‑entry _start

Copyright © 2005-2006. All rights reserved.DAI0150B