4.1. Makefile templates and standard build rules

The examples each include a makefile and link to the necessary retargeting code. The makefiles are all based around a series of templates that will allow you to rapidly adapt the examples to your own builds.

Configuration

Before the the supplied makefiles can be used they need be configured for the location and version of the CodeSourcery and RVCT installed. This can be done either automatically or manually.

Automatic Configuration

To configure the makefile automatically enter "make configure" from within the examples directory. This should detect the different versions of the tools installed on your computer and create common/an150_config.mk to store this information. This can be updated at a later time using "make reconfigure".

For the automatic configuration to be successful you must have the make utility, RVCT and the CodeSourcery tools on your PATH environment variable.

Manaul Configuration

If the automatic configuration is unsuccessful you can manually configure the make files. This is done by creating the file an150_config.mk in the common directory. Within this file you will need to declare the variables detailed below in Table 3.

Table 3. an150_config.mk configuration variables (continued)

Makefile variableDescription
CONFIG_CSL_ROOTIndicates the root of your CodeSourcery installation. On Linux this will be the directory in which you uncompressed the toolchain binaries package; on Windows this will be the directory chosen in the installer.For example: CONFIG_CSL_ROOT=/opt/codesourcery (Linux) CONFIG_CSL_ROOT=c:\codesourcery (Windows)
CONFIG_SP1This is used to indicate whether RVCT 3.0 (build 441) or RVCT 3.0 Service Pack 1 (build 586) is installed. RVCT 3.0 SP1 : CONFIG_SP1=1 RVCT 3.0 : CONFIG_SP1=0
CONFIG_CSL_RELConfigure the make files for the CodeSourcery release being used. For example CONFIG_CSL_REL=2006q1-6
CONFIG_CSL_GCC_VNUMSpecifies the GCC version number installedFor Example CONFIG_CSL_GCC_VNUM =4.1.0
CONFIG_CSL_CRT1_PATHIf you are using the 2006-Q1-3 CodeSourcery release, you must manually split the crt1.o object file. You must then use this to point to the strip version. If you are not using the 2006-Q1-3 CodeSourcery release this should point to the standard crt1.o object file.For Example CONFIG_CSL_CRT1_PATH =$(CONFIG_CSL_ROOT)/arm-none-linux-gnueabi/libc/usr/lib/crt1.o Please see section 5.1 Frequently Asked Questions for further details on crt1.o.

Application variables

The build rules in the template makefiles are controlled by a number of variables in the application makefile, as given below in Table 4.

Table 4. an150_config.mk configuration variables

Makefile variableDescription
CFLAGSAllows application-specific options to be given to the compiler. Most of the necessary options are provided by the makefile build rules, therefore the only options typically needed here are those required by your application.For example, you may use ‑D options to pass macro definitions to the compiler, optimization levels, or ‑I to specify your application's include paths.
LDFLAGSAllows application-specific options to be given to the linker. Most of the necessary options are provided by the makefile build rules, therefore the only options typically needed here are user library paths and switches that generate information about the application image, such as ‑‑info or ‑‑verbose.
OBJSLists the objects that must be compiled for the application
LIBSLists any additional libraries that your application links to
IMAGESpecifies the output filename for the image
ENABLE_DEBUGIf this is defined, debug information is left in the image. When this is not defined, debugging information is removed at the link step and fromelf is used on the final image to remove additional debug-related sections.

Makefile build rules

A number of functions are provided by the template makefiles for different build steps:

Table 5. Makefile build rules

Makefile function nameParametersDescription
compile_appsource file, object fileCompiles a source file using armcc. For example: $(call compile_app,foo.c,foo.o) compiles foo.c into the object file foo.o.
compile_libsource file, object fileCompiles a source file using armcc, built for linking into a shared library.
Gcc_appsource file, object fileThis rule is provided for convenience, to compile a source file using CodeSourcery's GCC.
Gcc_libsource file, object fileCompiles a source file using CodeSourcery's GCC, built for linking into a shared library.
assemble_appsource file, object fileUses armasm to assemble a source file.
assemble_libsource file, object fileUses armasm to assemble a source file, and marks the code as position-independent and therefore suitable for linking into a shared library.
link_appimage fileLinks the objects specified by $(OBJS) into the image file
link_liblibrary file, sonameLinks the objects specified by $(OBJS) into the dynamic library and gives it the specified shared object name. For example: $(call link_lib,libfoo.so.1.2,libfoo.so.1) links the library libfoo.so.1.2 but gives it the shared object name libfoo.so.1. This is commonly used to maintain different minor versions of a library in a filesystem.
gld_appimage fileLinks the objects specified by $(OBJS) into the image file using GNU ld
gld_libimage file, sonameLinks the objects specified by $(OBJS) into the dynamic library using GNU ld, and gives it the specified shared object name
fromelf_imageinput file, output fileRuns fromelf to strip debug data from an image
strip_imageimage fileRuns GNU strip on an image to remove debug data. This rule strips the file in place and does not create a separate, stripped copy.
armar_libarchive fileCreates (or updates) a static library using armar with the objects specified by the $(OBJS) variable
clean_filesfile listThis rule is provided to delete the specified files

Additional compiler and linker options

The template makefiles use some additional compiler and linker options that you may find useful when creating your own build scripts. These are described in Table 6.

Table 6. Additional compiler and linker options

SwitchDescription
--diag_suppress 6318,6319,6765The linker will typically generate a few warnings when building Linux applications, as described below. This switch suppresses these warnings. 6318 - These warnings are generated because GCC uses linker relocations for references internal to each object, whereas all such references are resolved at compile-time by armcc. The targets of these relocations may not have appropriate mapping symbols that allow the linker to determine whether the target is code or data, so ordinarily a warning will be generated 6319 - The standard makefiles use --keep to retain any .init, .fini, .init_array and .fini_array sections in your objects. This suppresses the warning that the linker is ignoring the --keep option when these are not present. 6765 - This is due to no build attributes being present in the GNU entry point code found in crt1.o, so the linker cannot determine which state (ARM or Thumb) the code will run in. It is safe to ignore this as the application entry code is ARM code.
--bss_threshold=0This switch instructs the compiler not to move small pieces of ZI (BSS) data into the read/write data section of the image. This reduces the size of the image.
Copyright © 2005-2006. All rights reserved.DAI0150B
Non-Confidential