3.1.  Issues with library linkage

There are a number of issues to consider regarding library linkage:

Avoiding semihosted RVCT functions

During development work, you may wish to add the following pragma directives to your code:

#pragma import __use_no_semihosting
#pragma import __use_no_heap_region

These causes armlink to generate an error if any semihosting library function is used, or if any of the ARM library heap functions (for example malloc()) are used.

Linking with compiler helper libraries

Whenever performing a link step to create an application or dynamic shared library, you must always link with an appropriate compiler helper library. Table 1 below summarizes which library you should choose for different circumstances.

When distributing a static library to a third party that has been created using RVCT, you may also need to include the objects from an appropriate helper library in your library in case these functions are not available to the user. Please note when manually selecting the libraries that the library names and contents may change between releases of the tools, and your build scripts or makefiles may need changing in the future to reflect this.

If in doubt, the best choice would be the h_t__uf.l library as this covers most typical uses, including linking your code into a shared library and cases where the application uses some Thumb code. You should consult the RVDS End-User License Agreement (EULA) for details of the restrictions on redistribution of the RVCT libraries, including the helper libraries.

Table 1. Compiler helper libraries

ARM/Thumb codein your application or library?Application orlibrary?Library to use
ARM code onlyApplicationh_a__un.l
Thumb code only ormixed ARM/Thumb codeApplicationh_t__un.l
ARM code onlyShared library or Applicationh_a__uf.l
Thumb code only ormixed ARM/Thumb codeShared library or Applicationh_t__uf.l

Controlling the functions that your application links with

Whether you are building a closed or open source application, you may want to ensure that no intellectual property covered by an incompatible license is linked into your application.

The best solution in this respect is to use the ‑‑no_scanlib linker option. This leaves the library selection under your full and explicit control. If you do not use this switch, the linker will by default search the system library path as given by the RVCT30LIB environment variable or the ‑‑libpath option. As a result, the linker may pull in additional functions that you did not intend to use. The details of the linker's library searching behavior can be found in section 7.2 of the RVCT 3.0 Linker and Utilities Guide.

For additional checks on which library functions are being included by the linker, you should consult the linker's verbose output. You can obtain this using the ‑‑verbose option, and redirected to a file using ‑‑errors filename.txt. This will produce full output including details of how the linker is searching for and selecting functions from libraries to resolve references in your object files.

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