Establishing arm gcc cross-compilation tool chain

Download address Gnu.org

binutils-2.21.1.tar.bz2

gcc-4.4.4.tar.bz2

glibc-2.11.2.tar.bz2

Glibc-ports-2.11.tar.bz2

Gmp-4.2.tar.bz2

Mpfr-2.4.0.tar.bz2

    Create a toolchain folder:

After creating the top-level folder embedded-toolchains, create the following directories under this folder:

Ø setup-dir, to store the downloaded compressed package;

Ø src-dir, stores the decompressed source files of binutils, gcc, and glibc;

Ø kernel, which stores kernel files and is also used for kernel configuration and compilation;

Ø build-dir, compile the source files under src-dir, which is the GNU recommended practice of separating the source file directory from the compile directory;

Ø tool-chain, the installation location of the cross-compilation tool chain;

Ø program, to store the written program;

Ø doc, description documents and script files;

    Create a directory below and copy the source files.

 Copy the source file:

Here we use the method of directly copying the source file. First, we should modify the permissions of setup-dir

[root@localhost embedded- toolchains]#chmod 777 setup-dir

Then directly copy the source files in the /home/karen directory to the setup-dir directory, as shown below:

 Create a compilation directory:

Output the following environment variables to facilitate our compilation.

To simplify the operation process, we will create a shell command script environment-variables:

[root@localhost build -dir] #cd ../doc

[root@localhost doc] #mkdir scripts

[root@localhost doc] #cd scripts

Use the editor vi to edit the environment variable script envionment-variables:

Screenshot below:

 %% Q: Why does it work when source ./environment-variables is used, but not when source is removed? %%

%% If you use source to execute, you do not need the script to have execution permissions, and permissions of 664 are also acceptable. The execution command is as follows:%%

%% Sourceenvironment-variables %%

 illustrate:

The TARGET variable is used to define the type of target board. The tool chain will be established based on the type of target board.

See Table 6-1. The definition of the target board has nothing to do with the type of host, but if you change the value of TARGET,

The GNU toolchain must be rebuilt once again.

The PREFIX variable provides a pointer to the directory where the target board utilities will be installed.

The TARGET_PREFIX variable points to the directory where the header files and libraries related to the target board will be installed.

The PATH variable points to the directory where binaries (executable files) will be installed.

If you are not used to using environment variables, you can use absolute or relative paths directly. If you do not use environment variables, you usually use absolute paths, and relative paths sometimes fail. Environment variables can also be defined in the .bashrc file, so you don't have to export these variables all the time.

The correspondence between the architecture and TAEGET variables is shown in Table 6-1:

Table 6-1 Correspondence between architecture and TAEGET variables

Binutils is one of the GNU tools, which includes connectors, assemblers and other tools for object files and archives. It is a binary code processing and maintenance tool. The programs included in the installation of Binutils tools are addr2line, ar, as, c++filt, gprof, ld, nm, objcopy, objdump, ranlib, readelf, size, strings, strip, libiberty, libbfd and libopcodes. A brief explanation of these programs is as follows.

Ø addr2line converts program addresses to file names and line numbers. Give it an address and an executable name on the command line, and it will use the executable's debugging information to figure out which file and line number is at the given address.

Ø ar creates, modifies, and extracts archive files. An archive file is a large file that contains the contents of multiple files, and its structure ensures that the original file contents can be restored.

Ø as is mainly used to compile the assembly files output by the GNU C compiler gcc, and the generated target files are connected by the connector ld.

Ø c++filt The linker uses it to filter C++ and Java symbols to prevent overloaded function conflicts.

Ø gprof displays various data of the program call segment.

Ø ld is the connector, which combines several target and archive files together, relocates data, and connects symbol references. Usually, the last step in building a new compiler is to call ld.

Ø nm lists the symbols in the object file.

Ø objcopy copies the contents of one type of target file to another type of target file.

Ø objdump displays information about one or more object files. Use options to control the information it displays. The information it displays is usually only of interest to people who write compilation tools.

Ø ranlib generates an archive file index and saves it to the archive file. The index lists the relocatable target files defined by each member of the archive file.

Ø readelf displays information of executable files in elf format.

Ø size lists the size of each section of the object file and the overall size. By default, only one line of output is generated for each object file or each module in an archive file.

Ø strings prints printable strings of a file, which are at least 4 characters long. You can also use the option -n to set the minimum length of the string. By default, it only prints printable characters in the initialization and loadable segments of the target file; for other types of files, it prints the printable characters of the entire file. This program is very helpful for understanding the contents of non-text files.

Ø strip discards all or specific symbols in the target file.

Ø libiberty contains functions used by many GNU programs, including getopt, obstack, strerror, strtol, and strtoul.

Ø libbfd binary file description library.

Ø libopcode is a library used to process opcodes. It is also used when generating some applications.

Binutils tool installation depends on Bash, Coreutils, Diffutils, GCC, Gettext, Glibc, Grep, Make, Perl, Sed, Texinfo and other tools

The following will introduce the process of installing binutils-2.19.2 step by step.

   Generate a Makefile in the build-binutils directory, and then execute make and make install. After completion, you can see our new binutil under $PREFIX/bin.

Note: The prefix of each tool's file name is the value set for the TARGET variable. If the target board is arm-linux, then the prefix of these tool's file names will be arm-linux-. This way, you can find the correct tool program according to the target board type.

Here we use the 2.6.29 kernel version. Because the cross-toolchain toolchain is for specific processors and operating systems, the Linux kernel needs to be configured before compiling. You can configure the kernel through the "make config" or "make menuconfig" command. After the configuration is completed, a .config file will be generated in the directory of the Linux source file. This is the file we need.

Note: The kernel version of the target board is 2.6.29

[root@localhost embedded- toolchains] #cdkernel

[root@localhost kernel] #tar jxvf../setup-dir/ linux-2.6.29.tar.bz2               

[root@localhost kernel] #bunzip2../setup-dir/ patch-2.6.29.bz2 

[root@localhost kernel] #cd linux-2.6.29

Patching the Linux kernel:

[root@localhost linux-2.6.29] #patch–p1 < http://www.cnblogs.com/setup-dir/patch-2.6.29

Then it is time to configure the kernel. The first step is to modify the Makefile

Modify Makefile:

ARCH =arm                         

CROSS_COMPILE = arm-linux-menuconfig  

Then use makemenuconfig to enter the kernel configuration menu

Or write directly:

# make ARCH=arm CROSS_COMPILE=arm-linux-menuconfig . Note that you must select the processor type when configuring. For example, my target machine uses an OMAP processor, so I choose TI OMAP:

System Type -à

         ARMSystem Type-à

         (x)TI OMAP

After configuration, exit and save.

After configuration, you need to execute make with the following parameters:

[root@localhost linux-2.6.29]# make ARCH=armCROSS_COMPILE=arm-linux- (It doesn’t matter if errors occur during execution. The main purpose is to generate header files version.h and autoconf.h)

After executing, check whether the /kernel/linux-2.6.29/include/linux/version.h and autoconf.h files in the kernel directory are generated. These are used to compile glibc. The existence of version.h and autoconf.h files indicates that you have generated the correct header files.

Next, create the include directory required by the toolchain and move the kernel header files over.

[root@localhost linux-2.6.29] #cd include

[root@localhost include] #ln -s asm-arm asm

You can check it out and it can be automatically generated after compilation. If the link has already been generated, you don't need to relink it. (2.6.29 has been automatically generated)

You can check it out and it can be automatically generated after compilation. If the link has already been generated, you don't need to relink it.

Header files to the installation directory of the cross-compilation tool chain:

Note: mach-xxx is selected according to the CPU type used by the target board

The purpose of this step is to build the arm-linux-gcc tool. Note that this gcc does not have the support of the glibc library, so it can only be used to compile programs that do not require C library support, such as the kernel and BootLoader. This compiler will also be used to create the C library later, so creating it is mainly to prepare for creating the C library. If you only want to compile the kernel and BootLoader, then you can end here after installing this. The installation process is as follows:

Starting from GCC-4.3, installing GCC will depend on GMP-4.1 or later and MPFR-2.3.2 or later. If you extract these two packages to the root directory of the GCC source tree and name them "gmp" and "mpfr" respectively, the GCC compiler will automatically compile them together with GCC. It is recommended to use the latest GMP and MPFR versions as much as possible.

l Because it is a cross compiler, the target board's system header files are not needed, so the option --without-headers needs to be used. Otherwise, there will be many errors that *.h header files cannot be found.

--enable-language=c is used to tell the configuration script what language the compiler needs to support. Now it only needs to support C language. Although it can be configured as C or C++

l --disable-threads is because threads requires the support of libc.

l --disable-decimal-float requires the support of libc, but we have not built libc during the initial compilation, otherwise the following error will appear: ../gcc-4.3.1/libgcc/config/libbid/bid_decimal_globals.c:52:18:error: fenv.h: No such file or directory ../gcc-4.3.1/libgcc/config/libbid/bid_decimal_globals.c:In function '__dfp_test_except':../gcc-4.3.1/libgcc/config/libbid/bid_decimal_globals.c:64:error: 'FE_INEXACT' undeclared (first use in this function)../gcc-4.3.1/libgcc/config/libbid/bid_decimal_globals.c:64:error: (Each undeclared identifier is reported only in once../gcc-4.3.1/libgcc/config/libbid/bid_decimal_globals.c:64:error: for each function it appears in.)

l --disable-shared, since this is the first time to install the ARM cross-compilation tool, the local glibc should support the local compilation tool library instead of the ARM cross-compilation tool library. forces GCC to link its internal libraries statically. Without this option, there will be crti.o: No such file: No such file or directorycollect2: ld returned 1 exit status

Note: Since there is no arm glibc, you need to use --disable-libmudflap --disable-libssp to disable the libraries used by the two boundary checks.

Similarly, since this is the first time to install the ARM cross-compilation tool, there is no header file for the supported libc library. In the src-dir/gcc-4.4.4/gcc/config/arm/t-linux file, add two definitions to TARGET_LIBGCC2_CFLAGS: -Dinhibit_libc –D__gthr_posix_h

Note: Many documents only have the first two items, which only builds gcc but not libgcc.a. This will cause an error that -lgcc is not found when compiling glibc. Report:

……/build-tools/build-glibc/libc_pic.a

i586-linux-gcc -nostdlib-nostartfiles -r -o/home/wei/workspace/mywork/moblin/build-tools/build-glibc/elf/librtld.map.o'-Wl,-(' /home/wei /workspace/mywork/moblin/build-tools/build-glibc/elf/dl-allobjs.os/home/wei/workspace/mywork/moblin/build-tools/build-glibc/libc_pic.a -lgcc'-Wl, -)'-Wl,-Map,/home/wei/workspace/mywork/moblin/build-tools/build-glibc/elf/librtld.mapT

/workspace/wei/mywork/moblin/tools/bin/../lib/gcc/arm-linux/4.4.4/http://www.cnblogs.com/http://www.cnblogs.com/ram- linux/bin/ld:cannot find -lgcc

In the compilation of glibc, libgcc_eh.a is also required (otherwise an error will occur: -lgcc_eh not found...bin/ld: cannot find-lgcc_eh). If the --disable-shared option is used, libgcc_eh.a will not be generated. This can be achieved by linking to libgcc.a.

  Note: There is a space between arm-linux-gcc and -print-libgcc-file-name

 Run the report:

"/workspace/wei/mywork/moblin/tools/bin/../lib/gcc/i586-linux/4.3.3/libgcc_eh.a"-> "libgcc.a"

After the installation is complete, check the results:

[root@localhost build-gcc] #ls$PREFIX/bin 

If tools such as arm-linux-gcc have been generated, it means that the boot trap gcc tool has been installed successfully.

  This step is the most tedious process. The target board must rely on it to execute or develop most applications. The glibc suite is often called the C link library, but glibc actually generates many link libraries, one of which is the C link library libc. Due to the limitations of embedded systems, the standard GNU C link library is too large to be used on the target board. Therefore, it is necessary to find a substitute for the C link library. Here, we take the standard GNU C as an example to establish a tool chain.

   Note: After completing the above, please check the file libc.so in the $TARGET_PREFIX/lib directory to see if the content of GROUP is specified to a library that can be used for cross-compilation. If not, please modify it as follows:

   libc.so file (located in $TARGET_PREFIX/lib), change GROUP (/lib/libc.so.6/lib/libc_nonshared.a) to GROUP (libc.so.6 libc_nonshared.a)

In this way, the linking program ld will look for the library it needs in the directory where libc.so is located, because your machine's /lib directory may already have a library with the same name, a library for compiling programs that can run on your host machine, not for cross-compilation.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

 After checking, I found that the GROUP in libc.so is already the directory of the cross-compilation chain, so there is no need to change it

Fixes to libc.so

 vi$PREFIX /${TARGET}/lib/libc.so

 Remove the absolute path, and the modified content is as follows:

 /*GNU ld script

     Use the shared library, but some functions are only in

     thestatic library, so try that secondarily. */

 OUTPUT_FORMAT(elf32-littlearm)

 GROUP( libc.so.6 libc_nonshared.a AS_NEEDED ( ld-linux.so.3 ) )

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%

Let's take a look at what's new in $PREFIX/bin. You'll find arm-linux-g++ and arm-linux-c++ files.

G++ - GNU's C++ compiler.

C++ - gnu's C++ compiler.

 root@localhost build-gcc] # cd$TARGET_PREFIX/bin

Check if the file is a binary file:

[root@localhost bin] # file as ar gccld nm ranlib strip   

View the default search path:

[root@localhost bin] #arm-linux-gcc-print-search-dirs  

    Let's write a simple C program using the established tool chain.

 The produced executable file hello can be run directly on the target machine.