Linking with third party libraries

[lpcware-support]

Introduction

In some projects, you may need to use library code supplied to you prebuilt by third parties. There should generally be few problems linking such library code into application being built using LPCXpresso IDE and the underlying GNU tools (gcc). This FAQ describes some of the issues that you might need to be aware of, particularly if the library was built using another toolchain.

Note: We would also strongly recommend reading the application note that ARM has on mixing code from different toolchains:

• ARM AN487 :  Binary Interoperability Between Toolchains

Library archive naming

The GNU tools require libraries to be named liblibrary_name.a. If the library was generated using a different toolchain, then you will need to rename it into this form. However, when you link with a library by adding it to:

Project -> Properties -> C/C++ Build -> Settings -> Tool Settings
      -> MCU Linker -> Libraries -> Libraries (-l)

you only specify library_name. For example, if you have a library called libmylib.a, you would specify mylib in the Linker Libraries settings. Note that you will also need to specify the location that you have placed the library archive in the Library search path (-L) setting.

Libraries and debug information

Generally if you are provided with a library archive, you will not have access to the source files. Thus you would normally expect that the producer of the library will have provided it without debug information being included within the archive.

However if the library has been provided with debug information still included, this can occasionally cause issues for the debugger as it tries to cope with debug information generated by different toolchains.

You can avoid such issues by stripping the debug information using the objcopy utility provided within the LPCXpresso \tools\bin subdirectory:

arm-none-eabi-objcopy --strip-debug libmylib.a

Note that removing such debug information will not reduce your ability to debug if you do not have access to the source files used to generate the library. It is also only removing debug information, so will have no affect on the code/data size of your actual application image.

Third party library must be AEABI compatible

If the third party library has been built with the Keil/RealView/ARM compiler tools, then in order to be compatible with other AEABI compatible toolchains (such as LPCXpresso IDE),  then the "--library_interface=aeabi_clib" armcc option should be used when building the library. Otherwise armcc carries out toolchain specific optimisations that require the explicit use of armlink and the ARM C library (ie the generated object/archive is only Keil/Realview/ARM compiler toolchain compatible). If this option was not specified when buiding the library, then this may generate linker errors from references to non-AEABI functions (commonly toolchain specific variants of printf family functions). For more information, see the ARM Compiler documentation at:

http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0472j/chr...http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0472j/chr...

wchar_t warnings

If the third party library has been built with a different toolchain, then you may see linker warnings highlighting that a specific object file "uses 2-byte wchar_t yet the output is to use 4-byte wchar_t". This warning can generally just be ignored and disabled. For more information, please see the FAQ "wchar_t warning when linking with library generated by another toolchain".

Floating point ABI

If the application and library are being targeted at Cortex-M4, then ensure that the floating point ABI options selected are compatible. For more information, please see the FAQ "Cortex-M4 Floating Point Support ".