嵌入式linux操作系统Chapter 4.doc

Chapter 4. Development ToolsMuch like mainstream software developers, embedded system developers need compilers, linkers, interpreters, integrated development environments, and other such development tools. The embedded developers tools are different, however, in that they typically run on one platform while building applications for another. This is why these tools are often called cross-platform development tools, or cross-development tools, for short.This chapter discusses the setup, configuration, and use of cross-platform development tools. First, I will discuss how to use a practical project workspace. I will then discuss the GNU cross-platform development toolchain, the C library alternatives, Java, Perl, Python, Ada, other programming languages, integrated development environments, and terminal emulation programs.4.1 Using a Practical Project WorkspaceIn the course of developing and customizing software for your target, you will need to organize various software packages and project components in a comprehensive and easy-to-use directory structure. Table 4-1 shows a suggested directory layout you may find useful. Feel free to modify this structure to fit your needs and requirements. When deciding where to place components, always try to find the most intuitive layout. Also, try to keep your own code in a directory completely separated from all the packages you will download from the Net. This will minimize any confusion regarding the sources ownership and licensing status.Table 4-1. Suggested project directory layoutDirectoryContentbootldrThe bootloader or bootloaders for your targetbuild-toolsThe packages and directories needed to build the cross-platform development toolchaindebugThe debugging tools and all related packagesdocAll the documentation you will need for your projectimagesThe binary images of the bootloader, the kernel, and the root filesystem ready to be used on the targetkernelThe different kernel versions you are evaluating for your targetprojectYour own source code for this projectrootfsThe root filesystem as seen by the targets kernel at runtimesysappsThe system applications required for your targettmpA temporary directory to experiment and store transient filestoolsThe complete cross-platform development toolchain and C libraryOf course, each of these directories contains many subdirectories. We will populate these directories as we continue through the rest of the book.The location of your project workspace is up to you, but I strongly encourage you not to use a system-wide entry such as /usr or /usr/local. Instead, use an entry in your home directory or a directory within the /home directory shared by all the members of your group. If you really want to have a system-wide entry, you may want to consider using an entry in the /opt directory. For the example embedded control system, I have the following layout in my home directory:$ ls -l /control-projecttotal 4drwxr-xr-x 13 karim karim 1024 Mar 28 22:38 control-moduledrwxr-xr-x 13 karim karim 1024 Mar 28 22:38 daq-moduledrwxr-xr-x 13 karim karim 1024 Mar 28 22:38 sysmgnt-moduledrwxr-xr-x 13 karim karim 1024 Mar 28 22:38 user-interfaceSince they all run on different targets, each control system component has a separate entry in the control-project directory in my home directory. Each entry has its own project workspace as described above. Here is the daq-module workspace for example:$ ls -l /control-project/daq-moduletotal 11drwxr-xr-x 2 karim karim 1024 Mar 28 22:38 bootldrdrwxr-xr-x 2 karim karim 1024 Mar 28 22:38 build-toolsdrwxr-xr-x 2 karim karim 1024 Mar 28 22:38 debugdrwxr-xr-x 2 karim karim 1024 Mar 28 22:38 docdrwxr-xr-x 2 karim karim 1024 Mar 28 22:38 imagesdrwxr-xr-x 2 karim karim 1024 Mar 28 22:38 kerneldrwxr-xr-x 2 karim karim 1024 Mar 28 22:38 projectdrwxr-xr-x 2 karim karim 1024 Mar 28 22:38 rootfsdrwxr-xr-x 2 karim karim 1024 Mar 28 22:38 sysappsdrwxr-xr-x 2 karim karim 1024 Mar 28 22:38 tmpdrwxr-xr-x 2 karim karim 1024 Mar 28 22:38 toolsBecause you may need to provide the paths of these directories to some of the utilities you will build and use, you may find it useful to create a short script that sets appropriate environment variables. Here is such a script called develdaq for the DAQ module:export PROJECT=daq-moduleexport PRJROOT=/home/karim/control-project/$PROJECTcd $PRJROOTIn addition to setting environment variables, this script moves you to the directory containing the project. You can remove the cd command if you would prefer not to be moved to the project directory right away. To execute this script in the current shell so that the environment variables are immediately visible, type:11 All commands used in this book assume the use of the sh or bash shell, because these are the shells most commonly used. If you use another shell, such as csh, you may need to modify some of the commands accordingly.$ . develdaqFuture explanations will rely on the existence of the PROJECT and PRJROOT environment variables.Since the distribution on your workstation has already installed many of the same packages you will be building for your target, it is very important to clearly separate the two types of software. To ensure such separation, I strongly encourage you not to carry out any of the instructions provided in the rest of this book while being logged in as root, unless I provide explicit instructions otherwise. Among other things, this will avoid any possible destruction of the native GNU toolchain installed on your system and, most importantly, the C library most of your applications rely on. Therefore, instead of logging in as root, log in using a normal user account with no particular privileges.4.2 GNU Cross-Platform Development ToolchainThe toolchain we need to put together to cross-develop applications for any target includes the binary utilities, such as ld, gas, and ar, the C compiler, gcc, and the C library, glibc. The rest of the discussion in the later chapters relies on the cross-platform development toolchain we will put together here.You can download the components of the GNU toolchain from the FSFs FTP site at /gnu/ or any of its mirrors. The binutils package is in the binutils directory, the gcc package is in the gcc directory, and the glibc package is in the glibc directory along with glibc-linuxthreads. If you are using a glibc version older than 2.2, you will also need to download the glibc-crypt package, also from the glibc directory. This part of the library used to be distributed separately, because U.S. cryptography export laws made it illegal to download this package to a computer outside the U.S. from the FSFs site, or any other U.S. site, for that matter. Since Version 2.2, however, glibc-crypt has been integrated as part of the main glibc package and there is no need to download this package separately anymore.2 Following the project directory layout suggested earlier, download the packages into the $PRJROOT/build-tools directory.2 The following email from the glibc developer mailing list covers the folding of glibc-crypt into the main glibc package and conformance to U.S. export laws: /ml/libc-alpha/2000-02/msg00104.html. This email, and the ensuing thread, refer to the BXA abbreviation. This is the Bureau of Industry and Security of the U.S. Department of Commerce (/). It is known as the BXA, because it was formerly the Bureau of Export Administration.Note that all the targets discussed in Chapter 3 are supported by the GNU toolchain.4.2.1 GNU Toolchain BasicsConfiguring and building an appropriate GNU toolchain is a complex and delicate operation that requires a good understanding of the dependencies between the different software packages and their respective roles. This knowledge is required, because the GNU toolchain components are developed and released independently from one another. Component versionsThe first step in building the toolchain is selecting the component versions we will use. This involves selecting a binutils version, a gcc version, and a glibc version. Because these packages are maintained and released independently from one another, not all versions of one package will build properly when combined with different versions of the other packages. You can try using the latest versions of each package, but this combination is not guaranteed to work either.To select the appropriate versions, you have to test a combination tailored to your host and target. Of course, you may find it easier to ask around and see whether someone somewhere tested a certain combination of versions for that setup and reports that her combination works correctly. You may also have to try such combinations for your setup on your own if you do not find a known functional version combination. In that case, start with the most recent stable versions of each package and replace them one by one with older ones if they fail to build.In some cases, the version with the highest version number may not have had the time to be tested enough to be considered stable. At the time glibc 2.3 was released, for example, it may have been a better choice to keep using glibc 2.2.5 until 2.3.1 became available.At the time of this writing, for instance, the latest version of binutils is , the latest version of gcc is 3.2.1, and the latest version of glibc is 2.3.1. Most often, binutils will build successfully and you will not need to change it. Hence, let us assume that gcc 3.2.1 fails to build although all the appropriate configuration flags have been provided. In that case, I would revert to gcc 3.2. If that failed, I would try 3.1.1 and so on. It is the same thing with glibc. Version 2.3.1 of glibc may fail to build. In that case, I would revert to 2.3 and later to 2.2.5, if necessary.You must understand, however, that you cannot go back like this indefinitely, because the most recent package versions expect the other packages to provide certain capabilities. You may, therefore, have to go back to older versions of packages that you successfully built if the other packages down the line fail to build. Using the above versions, for example, if I had to go back to glibc 2.1.3, it might be appropriate to change back to gcc 2.95.3 and binutils 2.10 although the most recent gcc and most recent binutils may have compiled perfectly.You may also need to apply patches to some versions to get them to properly compile for your target. The web sites and mailing lists provided for each processor architecture in Chapter 3 are the best place to find such patches and package versions suggestions. Another place to look for patches is in the Debian source packages. Each package contains the patches required for all the architectures supported by that package.Table 4-2 provides a list of known functional version combinations. For each host/target combination, known compatible versions are provided for binutils, gcc, and glibc. The last column indicates whether the tools require patching.Table 4-2. Known functional package version combinationsHostTargetKernelbinutilsgccglibcPatchesi386PPCNoPPCi38NoPPCi38.1Noi386ARM2.4.1-rmkYes3PPCARMYes3i386MIPS2.8.1egcs-.6Yes4i386SuperH.12.2.4Yes5Sparc (Solaris)PPC2.4.0No3 See The -Dinhibit_libc hack subsection in the Building the Toolchain section of The GNU toolchain chapter in AlephOnes Guide to ARMLinux for Developers (http:/www.aleph1.co.uk/armlinux/book/book1.html) for further information on the modifications to be made to gcc to make it build successfully.4 See Ralf Bchles MIPS HOWTO (/ ) for further information on the patches to apply.5 See Bill Gatliffs Running Linux on the Sega Dreamcast (/articles/AT7466555948.html ) for further information on the patches to apply.Some of the combinations presented were on the Net as part of cross-platform development toolchain setups. I have kept the kernel version when the original explanation provided one. The kernel version, however, does not really matter for the build of the toolchain. Any recent kernelVersion 2.2.x or 2.4.xknown to work for your target can be used for the toolchain build. I strongly recommend using the actual kernel you will be using in your target, however, to avoid any future conflicts. I will discuss kernel selection in Chapter 5.Although it is not specifically mentioned in the table, there is one glibc add-on that we will need for the toolchain: glibc-linuxthreads. The packages versions closely follow glibcs numbering scheme. Hence, the linuxthreads version matching glibc 2.2.3 is linuxthreads Version 2.2.3. Although I recommend getting the linuxthreads package, you should be able to build glibc without it. Note that glibc 2.1.x, for instance, does not build properly without linuxthreads. If you are using glibc 2.1.x, remember that you will also need to download the glibc-crypt add-on if you intend to use DES encryption.By no means is Table 4-2 complete. There are many other combinations that will work just as well. Feel free to try newer versions than the ones presented. Use the same technique discussed earlier by starting with the latest versions and decrementing versions as needed. At worst, you will have to revert to setups presented above.Whenever you discover a new version combination that compiles successfully, make sure you test the resulting toolchain to ensure that it is indeed functional. Some version combinations may compile successfully and still fail when used. Version 2.2.3 of glibc, for example, builds successfully for a PPC target on an x86 host using gcc 2.95.3. The resulting library is, nevertheless, broken and will cause a core dump when used on the target. In that particular setup, we can obtain a functional C library by reverting to glibc 2.2.1.There are also cases where a version combination was found to work properly on certain processors within a processor family while failing to work on other processors of the same family. Versions of glibc earlier than 2.2, for example, worked fine for most PPC processors except those that were part of the MPC8xx series. The problem was that glibc assumed 32-byte cache lines for all PPC processors, while the processors in the MPC8xx series have 16-byte cache lines. Version 2.2 fixed this problem by assuming 16-byte cache lines for all PPC processors.The following sections describe the building of the GNU toolchain for a PPC host and an i386 target using binutils 2.10.1, gcc 2.95.3, and glibc 2.2.3. This was the second entry in Table 4-.2 Build requirementsTo build a cross-platform development toolchain, you will need a functional native toolchain. Most mainstream distributions provide this toolchain as part of their packages. If it was not installed on your workstation or if you chose not to install it to save space, you will need to install it at this point using the procedure appropriate to your distribution. With a Red Hat distribution, for instance, you will need to install the appropriate RPM packages.You will also need a valid set of kernel headers for your host. These headers must usually be located in the /usr/include/linux, /usr/include/asm, and /usr/include/asm-generic directories, and should be the headers used to compile the native glibc installed on your system. In older distributions, and in some installations still, these directories are actually symbolic links to directories within the /usr/src/linux directory. In turn, this directory is itself a symbolic link to the actual kernel installed by your distribution. If your distribution uses the older setup, and you have updated your kernel or modified the content of the /usr/src/linux directory, you will need to make sure the /usr/src/linux symbolic link is set appropriately so that the symbolic links in /usr/include point to the kernel that was used to build your native glibc, and that was installed by your distribution. In recent distributions, however, the content of /usr/include/linux, /usr/include/asm, and /usr/include/asm-generic is independent of the content of /usr/src/linux, and no kernel update should result in such problems. Build overviewWith the appropriate tools in place, let us take a look at the procedure used to build the toolchain. These are the five main steps:Kernel headers setupBinary utilities setupBootstrap compiler setupC library setupFull compiler setupThe first thing that you probably noticed, looking at these steps, is that the compiler seems to be built twice. This is normal and required, because some languages supported by gcc, such as C+, require glibc support. Hence, a first compiler is built with support for C only, and a full compiler is built once the C library is available.Although I placed the kernel headers setup as the first step, the headers will not be used until the C library setup. Hence, you could alter the steps and set up the kernel headers right before the C library setup. Given the workspace directory layout we are using, however, you will find the original ordering of the steps given above to be more appropriate.Obviously, each step involves many iterations of its own. Nonetheless, the steps remain similar in many ways. Most toolchain build steps involve carrying out the followi