3.3. Library linkage under particular licensing conditions

This section provides a very broad overview of the mechanisms that you can use when linking a closed-source application or one containing material covered by one or more open-source licenses. This is a purely technical overview and for all legal concerns you should consult your own legal advisors.

Linking closed-source applications

In the closed-source case, you may use additional features provided by the RVCT libraries provided that your use of the libraries is permitted by the RVDS End-User License Agreement. There are two options:

  • Use ‑‑no_scanlib and explicitly specify one or more RVCT libraries or their member functions on the linker command line.

    This provides full control over exactly which functions are used. However, you must be careful which libraries you use for different circumstances. In particular, you must use the position independent variant of a library whenever linking its objects into a dynamic shared library. You should also use the Thumb variant of a library whenever any Thumb code is present in your application. Details of library naming can be found in section 5.16 of the RVCT 3.0 Compiler and Libraries Guide.

  • Allow the linker to search the RVCT libraries as it would by default.

    You should ensure that all input and output routines are provided by additional libraries such as the GNU C library (glibc), which are given on the linker command line. Also take additional care that no other semihosting functions or heap-using functions are linked into your image. See "Avoiding semihosted RVCT functions" in section 3.1.1 above for further details.

Also note that the ARM libraries provide a complete signal-handling interface that can be linked into an application for a number of reasons, such as to handle division by zero. These signal-handling functions are required in a bare-metal environment. However, they may not be needed in a Linux application and in such cases should be retargeted to use Linux system calls. A detailed discussion of such retargeting is beyond the scope of this Application Note. The same ABI function from the GNU libraries will be functionally equivalent, without the need for any additional work.

As with any other application, you are responsible for ensuring that the objects and libraries you provide to the linker are covered by compatible licenses. If you are concerned about linking with code from an incompatible license, it is recommended that you use the ‑‑no_scanlib option as above and select the library functions used in your image very carefully. In such circumstances, we again suggest that you speak to your legal advisors about such licensing concerns.

Linking open-source applications

With open-source applications, it is important to understand the licensing terms your code is covered by and the implications of those terms. You must be happy that everything you link with is covered by compatible license terms. Please note that the RVCT C and C++ libraries are not available under an open-source license.

The only safe way of doing this is to use the ‑‑no_scanlib linker option and explicitly specify the libraries that you wish to link with.

Interoperation of toolchains

When using a combination of the GNU tools and RVCT to build an application or library, additional care must be taken.

Limitations and restrictions on builds shared between toolchains

There are a number of differences between GCC and the RVCT compiler that may affect your ability to build the code with either toolchain. In particular, note that:

  • GCC inline assembly code is not compatible with RVCT and vice versa

  • Likewise, standard assembly language files cannot be built by both armasm and the GNU assembler (gas) as they use different syntax

  • RVCT 3.0 supports the C90 standard with some elements of C99, rather than the full C99 standard. You may find that you need to make some changes to your source code to take account of this, if it uses C99 features

  • Certain language extensions supported by GCC are not implemented by RVCT; this includes any implementation-specific #pragma directives

In some circumstances, you may be able to conditionally define around such code to allow building with both toolchains where this is important.

Limitations on builds using objects generated by both toolchains

Other limitations restrict how you can use objects compiled with both toolchain in the same application or library:

  • Linking C++ objects compiled with both RVCT and GCC is particularly difficult from a legal perspective and is not recommended by ARM. The interfaces between C++ objects are complex in nature at both the binary and source levels. The simplest solution is to link an entire C++ application using only one toolchain.

  • "When linking RVCT objects using GNU ld, the RVCT objects must have been compiled using ‑‑dwarf2. By default RVCT uses DWARF3 debug data, however GNU ld is unable to read DWARF3 debug data. Therefore the objects must be compiled with DWARF2 debug data.

  • For C applications and C++ objects whose interfaces are all C (i.e. all functions and data are declared extern "C"), there should be no barriers. However, you are responsible for ensuring that all of the intellectual property in your application is used in a way that does not violate their license terms.

Copyright © 2005-2006. All rights reserved.DAI0150B
Non-Confidential