Search

'toolchain'에 해당되는 글 4건

  1. 2006.09.14 toolchain downloads
  2. 2006.09.14 crosstool-howto
  3. 2006.09.14 Toolchain for SMDK2410X targets HOWTO
  4. 2006.09.14 내장형시스템 실습 1주차

toolchain downloads

만드는 일/장치 2006.09.14 23:13 Posted by soulfree >동네청년<
http://falinux.com/pds/toolchain.html
신고

'만드는 일 > 장치' 카테고리의 다른 글

한백전자 사이트  (0) 2006.09.15
한백전자의 EMPOS-II  (2) 2006.09.14
toolchain downloads  (0) 2006.09.14
crosstool-howto  (0) 2006.09.14
Toolchain for SMDK2410X targets HOWTO  (0) 2006.09.14
내장형시스템 실습 1주차  (0) 2006.09.14

crosstool-howto

만드는 일/장치 2006.09.14 23:03 Posted by soulfree >동네청년<

crosstool-howto

Crosstool is a set of scripts to build and test several versions of gcc and glibc for most architectures supported by glibc. It will even download and patch the original tarballs for you. The resulting script and associated patches, and the latest version of this doc, are available at kegel.com/crosstool.

Crosstool was originally developed for embedded system developers, but is also useful for mainstream developers who simply want their compiles to go fast or who need to build programs that run on older versions of Linux (e.g. Red Hat 6.2), but don't want to develop on those ancient systems.

It includes minimal patches for gcc and glibc needed to build a few combinations of (alpha, arm, i686, ia64, mips, powerpc, powerpc64, sh4, sparc, sparc64, s390, x86_64) x (gcc-2.95.3 ... gcc-4.0.0) x (glibc-2.1.3 ... glibc-2.3.5).

It also supports building toolchains that target Cygwin; see demo-cygwin.sh.

Crosstool is a portable shell script. You can use it to build linux-targeted compilers that run on Linux, Mac OS X, Solaris, and Cygwin. It includes support for creating hetrogenous build clusters; it lets you use virtually every computer in the building, regardless of operating system or CPU type, to speed up your Linux compiles.

Contents

Quick Start

Download and unpack. For instance:
wget http://kegel.com/crosstool/crosstool-0.38.tar.gztar -xzvf crosstool-0.38.tar.gzcd crosstool-0.38
Then look at the demo scripts; there's one for each supported CPU type. For instance, demo-i686.sh is an example of how to build a toolchain that targets the i686 processor. It sets three important variables:
TARBALLS_DIR=$HOME/downloads        # where it will save source tarballsRESULT_TOP=/opt/crosstool           # where it will install the toolsGCC_LANGUAGES="c,c++,java,f77"      # which languages it will make compilers for
It then builds gcc-3.4.0 and glibc-2.3.2 for i686 with the line
 eval `cat i686.dat gcc-3.4.0-glibc-2.3.2.dat`  sh all.sh --notest 
Edit the script if you want to change any of these settings or versions. Then (as root) create the directory /opt/crosstool and make it writable by you, and finally (as yourself) run the demo script, e.g.
sudo mkdir /opt/crosstoolsudo chown $USER /opt/crosstoolsh demo-i686.sh
When it finishes, you can run the new compiler as /opt/crosstool/gcc-3.4.0-glibc-2.3.2/i686-unknown-linux-gnu/bin/i686-unknown-linux-gnu-gcc. (You might want to put /opt/crosstool/gcc-3.4.0-glibc-2.3.2/i686-unknown-linux-gnu/bin on your PATH; then you can run the compiler as i686-unknown-linux-gnu-gcc.)

Static Builds

If for some reason you want the resulting toolchain binaries to be statically linked, set the following environment variables before running crosstool.sh (or all.sh):
BINUTILS_EXTRA_CONFIG="LDFLAGS=-all-static"GCC_EXTRA_CONFIG="LDFLAGS=-static"

Building RPMs

Building RPMs of the compiler used to be done by the same shell script, all.sh, with the --buildrpm option, but that was not enough to satisfy real Linux distributions, which require true .src.rpm's. So now the procedure to build an RPM is to first build the .src.rpm, then build the .rpm from that, using rpmbuild in the traditional way.

A script demonstrating how to build .src.rpm's is buildsrpms.sh. A script demonstrating how to build both .src.rpm's and .rpm's is buildrpms.sh. Both of these are only examples; I use them myself to build a specific set of toolchains.

Each .src.rpm generated by buildsrpms.sh builds toolchains for all supported CPUs, where 'supported' means 'the CPU is listed in the buildlogs directory as having successfully built a working toolchain'. This greatly cuts down on the number of .src.rpm's needed. To build for just e.g. i686, run rpmbuild with options "--without all --with i686".

Faster builds with distcc

You can use distcc to distribute compilation across multiple computers for faster compiles. The distcc that comes with your version of Linux will work fine for most cases. However, it may be more convenient to instead use the script 'mkdistcc.sh' included with crosstool to install a crosstool-specific distcc (partly because that's what the mkdistcclinks.sh script assumes, and partly because it includes a patch that improves support for large hetrogenous clusters; see below).

To install distcc/distccd from source, run

RESULT_TOP=/opt/crosstool \TARBALLS_DIR=$HOME/downloads \sh mkdistcc.shcd /opt/crosstoolsh common/bin/mkdistcclinks.sh
To set up distccd as a service, run
sudo sh /opt/crosstool/common/bin/install-distccd.sh

Regardless of how you installed crosstool-distcc, you then need to edit /opt/crosstool/common/etc/hosts and append the hostnames of all the computers running your distccd.

You can then run the distributed compiler as /opt/crosstool/gcc-3.3.3-glibc-2.3.2/i686-unknown-linux-gnu/distributed/bin/i686-unknown-linux-gnu-gcc. (You might want to put /opt/crosstool/gcc-3.3.3-glibc-2.3.2/i686-unknown-linux-gnu/distributed/bin on your PATH; then you can run the distributed compiler as i686-unknown-linux-gnu-gcc.)

To get any speed benefit, you'll need to run several compiles in parallel. See e.g. make's -j option. Also note that only simple compiling with the -c option, not linking, is sped up, and that only C and C++ compiles are distributed (fortran and java compiles are not distributed, sorry).

Getting the best performance out of distcc is a fine art. See e.g. Benjamin Meyer's page "Distcc optimizations and how to compile kdelibs from scratch in six minutes".

You can monitor your distcc jobs by running

/opt/crosstool/common/bin/distccmon-test 5
This will display a description of your active remote jobs once every five seconds.

Hetrogenous distcc clusters

Here's a scenario sometimes useful at large universities or companies, where one often has a central file server which all clients access. Crosstool is built for multiple versions of gcc and glibc, once for kind of workstation in the cluster, and installed in e.g. /shared/crosstool/`config.guess`. Compilers are invoked via absolute paths so toolchains with different versions of glibc can be distinguished. The absolute path is built using config.guess so, regardless of which kind of workstation the developer is on, he or she can invoke a compiler that can run on their workstation.

For example, when building a C program for modern x86 linux, developers set

CC=/shared/crosstool/`config.guess`/gcc-3.3.3-glibc-2.3.2/i686-unknown-linux-gnu/distributed/bin/i686-unknown-linux-gnu-gcc
And when building a C program for old Red Hat Linux 6.2 x86, developers might set
CC=/shared/crosstool/`config.guess`/gcc-3.3.3-glibc-2.1.3/i686-unknown-linux-gnu/distributed/bin/i686-unknown-linux-gnu-gcc

A tricky part of this scenario is that the distcc server needs to be able to handle absolute paths for *other* architectures, possibly installed at a different location. The patch patches/distcc-2.14/distcc-stringmap.patch, applied by mkdistcc.sh, adds a feature to the distccd server to read a $prefix/etc/distcc/apps file containing absolute paths to all known compilers, and to ignore all but the last N path components when locating the compiler to satisfy received compile requests. The distccd startup scripts created by crosstool's install-distccd.sh turn on that feature.

gcc-3.4.0's precompiled headers and profile-driven optimization features require lockstep synchronization, so they probably work only if the client and the server are the same CPU type and operating system. (And using pch with distcc may require apple's -fpch-preprocess patch; see http://gcc.gnu.org/ml/gcc/2003-03/msg00369.html)

Canadian Cross Builds

Those long, strange names of the form "i686-unknown-linux-gnu" are called GNU configuration names. The GNU build and test scripts use these extensively. When you run the demo-$CPU.sh script, it sources the $CPU.dat file, which sets a variable TARGET containing the GNU configuration name for the target CPU. For instance, i686.dat contains the line
TARGET=i686-unknown-linux-gnu
In the general case, there can be three machine types: the build machine which builds the compilers, the host machine where the compilers will run, and the target machine for which the compilers will generate code.

Building compilers that will run on some other linux system is called a Canadian Cross. It's useful if, say, you're putting together a hetrogenous build cluster consisting of 32 bit and 64 bit workstations, and you want to run natively compiled compilers on each.

To do a Canadian Cross build with crosstool, you have to run it three times:

  1. once to build a toolchain that runs on the build system and generates code for the host system
  2. once to build a toolchain that runs on the build system and generates code for the target system
  3. once to build a toolchain that runs on the host system and generates code for the target system
The last two runs are identical except that on the last run, you have to set a few environment variables:
  • GCC_HOST should be the GNU configuration name (e.g. powerpc-750-linux-gnu) of the host machine
  • PATH must be set to include the bin directory of the host and target compilers that can run on the build machine
  • CC and AR have to be set to a compiler that generates code that runs on the host, and a version of ar that can handle archives of code for the host.
demo-canadian.sh (when I finish it) will demonstrate how to get this working.

If you want the use resulting toolchain as a native toolchain, i.e. if you want it to search /lib and /usr/lib, you'll probably need to edit its specs file to set the cross_compiler parameter to 0; see this thread in the crossgcc mailing list.

Scripts

  • crosstool.sh: Compiles gcc and glibc. This is the most important file, and it can be used by itself, without any other files from the tarball, if you are so inclined.
  • getandpatch.sh: Download, unpack, and patch the binutils, linux, gcc, and glibc source tarballs.
  • crosstest.sh: Run the gcc and glibc regression tests remotely.
  • ptx.sh: Build userland apps (e.g. /bin/sh) using ptxdist.
  • testhello.sh: Verifies trivial programs can be built with the new compiler
  • all.sh: Invoke all the above scripts. Supposedly more convenient that running them individually. (See below.)
  • mkdistcc.sh: A script to download, build, and patch distcc.
  • mkdistcclinks.sh: A script to create masquerade directories for each installed compiler to make using distcc easier.
  • demo-CPU.sh: One demo script for each CPU type that sets environment variables for that CPU, then runs all.sh and mkdistcc.sh.
  • demo.sh: Big demo script that runs all the little demo-CPU.sh scripts.
  • clean.sh: remove junk files; used by maintainer before creating tarballs
  • mkjail.sh: create the files needed for a chroot jail (useful when doing regression testing of glibc)
  • testjail.sh: test a remote chroot jail

Data Files

  • CPU.dat: One file for each CPU type; sets GNU target name
  • gcc-VERSION-glibc-VERSION.dat: One file for each supported combination of gcc and glibc; sets binutils, gcc, and glibc versions and options
  • patches/PROGRAM/*.patch: the patches I needed for each version of each program. The patches for each tool are stored in a subdirectory of patches/ named after the tool (e.g. patches/gcc-3.3). Each patch starts with comments about what it's for, and has links to any associated discussion. This is a small but hopefully high quality and maintainable patch repository; newer versions of ptxdist use a mirror of this repository.
  • summaries/*: example outputs from old crosstest.sh runs

Notes

If you want to build gcc-3.3 or later, you'll need a recent gcc (3.2 or later) on your workstation to build it with.

The scripts are fairly generic. You may need to tweak the parameters of the script to match your exact CPU type, or add a few patches needed to the patches/* directories, and run the build script again, if your tests indicate that programs built with the new compiler have problems.

In particular, if your CPU lacks an FPU, you might need to tell glibc that by setting before running all.sh. For example, see powerpc-405.dat, which sets

GLIBC_EXTRA_CONFIG="--without-fp"

Once you trust the toolchain can build and run simple statically linked 'hello, world' programs (see e.g. testhello.sh), test it with real applications.

If you use these scripts to build a toolchain, please send a note to the crossgcc mailing list indicating which platform you used it on, and how well it worked for you. Please be sure to mention which release of the crosstool scripts you used.

If you add support for a new CPU type, please send your changes to the crossgcc mailing list so they can be incorporated in a future release.

Testing

If you're targeting i686-linux, and are using a released version of gcc and glibc, you probably don't need to worry about testing the toolchain.

But if you're using a new or uncommon CPU type, or an unreleased version of gcc or glibc, and want some assurance that you have built a working compiler and C library, you should run the gcc and glibc test suites. See crosstest-howto.html.

all.sh

all.sh invokes the four scripts that download, build, and test the toolchain. It takes four options:
  • --nounpack, which means 'don't run getandbuild.sh'. This is useful for quick reruns or when just testing.
  • --nobuild, which means 'don't run crosstool.sh'. This is useful for when you just want to run regression tests.
  • --builduserland, which means 'run ptx.sh'. This is useful for when you need to build busybox for some reason, e.g. if you want to run the regression tests, but the target's normal shell can't run against the new shared C libraries.
  • --notest, which means 'don't run crosstest.sh'. This is useful for when you don't have a target to test on, or don't want to spend the time to test. See crosstest-howto.html for information about running the test suite.

Build Platform Notes

Linux

Crosstool was developed on Linux, so most of the rough edges have been polished off. However, if running crosstool.sh on Linux fails with an error like
"soinit.c:25: internal compiler error: in named_section_flags, at varasm.c:..."
then you may be running into gcc bug 9552. One workaround is to delete the file gcc-pr-9552-workaround.patch from crosstool/patches/glibc-2.3.2, and rerun. Another is to switch to a different version of binutils (2.14 seems to be the dividing line).

NetBSD

You'll need to install GNU Diffutils or GNU Patch, since BSD's patch utility doesn't accept the --fuzz parameter.

Mac OS X

You need to install gawk, gnu sed, and wget before you can build crosstool on Mac OS X. The way I installed them was using fink, but DarwinPorts would probably do as well.

On some (older?) versions of Mac OS X, you'll need to raise the stack size with the command

ulimit -s 8192
else make may segfault.

If wget or any other fink program segfaults, try 'sudo /sw/var/lib/fink/prebound/update-package-prebinding.pl -f' once to get around a hiccup in fink's incremental prelinking of apps. See the fink FAQ.

When using 2.6 kernel headers on systems (like Mac OS X) where gcc doesn't support the -shared flag, you may see the error

gcc: unrecognized option `-shared'ld: Undefined symbols:_mainmake[1]: *** [scripts/kconfig/libkconfig.so] Error 1make: *** [oldconfig] Error 2 
This is a well-known issue (see e.g. Peter Samuelson's post of 7 Nov 2002 Bertrand Marquis a patch that might help on 29 June 2004. It would be nice if someone figured out a patch that could go into the mainline kernel sources to deal with this issue.

Another problem building Linux on Mac OS X is described, together with a Mac OS X specific workaround, by Martin Schaffner's post of 22 May 2004.

Cygwin

Crosstool, and probably gcc and glibc's configure scripts, assume that directory names do not contain any spaces. This is often violated on Windows. Please take care to not use directory names with spaces in them when running crosstool. It might work, but if it doesn't, you've been warned. (Same goes for Mac OS X.)

This isn't really a crosstool problem, but configuring linux-2.6 on cygwin may fail with the error

$ make menuconfig HOSTCC  scripts/basic/fixdep HOSTCC  scripts/basic/split-include HOSTCC  scripts/basic/docproc HOSTLD  scripts/kconfig/mconfcollect2: ld terminated with signal 11 [Segmentation fault], core dumped
A possible fix described e.g. by Bertrand Marquis' post of 29 June 2004 is to patch linux-2.6/scripts/kconfig/Makefile to just use libkconfig.o rather than first making a .so.

Cygwin-1.5.9-1 had a bug that prevents it from building glibc. You can work around this by updating to Cygwin-1.5.10-2.

Solaris Build Considerations

Crosstool ought to build on Solaris as long as it has been updated with the appropriate set of GNU tools, but this has not been tested.

binutils-2.15 may require this patch to work on Solaris, else it is said to segfault when building the Linux kernel.

glibc documents which GNU tools it requires in its INSTALL file. The list is roughly: make 3.79, GCC 3.2, binutils 2.13, texinfo 3.12f, awk 3.0, sed 3.02, or newer. gcc documents a few other requirements in gcc.gnu.org/install/specific.html, which says that gcc won't build at all with the default solaris shell, and you're supposed to work around it like this:

% CONFIG_SHELL=/bin/ksh% export CONFIG_SHELL
before running crosstool.

That page also advises that you may need to install some Solaris patches, and install gcc-3.2.3 or newer before trying to build newer versions of gcc.

Troubleshooting

Download Problems

all.sh calls getandpatch.sh, which looks in the directory specified by TARBALLS_DIR for source tarballs, and downloads them to there if not found.

If the download hangs, and you need to use a proxy, try telling wget about your proxy before running all.sh by doing

$ export http_proxy=<proxy_host>:<port>
If the download still hangs, download the tarball that's causing the hang manually to the directory specified by TARBALLS_DIR.

Current Issues

  • all.sh's --builduserland seems to be broken at the moment.
  • NPTL is not yet supported.
  • These scripts, unlike Bill Gatliff's original crossgcc scripts, don't support bare metal newlib targets. They should, but I needed to focus on targeting Linux first. See contrib/newlib for a user-contributed fix.
  • These scripts don't support uClibc yet, but see below.
  • The hppa target is not yet supported.
  • glibc-2.3.2 doesn't build for cris; looks like the maintainer needs to create a sysdep-cancel.h for cris. I no longer try cris, since it seems to be unmaintained.
See the ChangeLog for more issues.

Build Status

The script regtest-run.sh tries to build a number of combinations of gcc, glibc, and CPU, and saves the last hundred or so lines of the build log in the file buildlogs$cpu-$gcc-$glibc.log.txt, along with a summary of the build in the file buildlogs$cpu-$gcc-$glibc.dat.txt. The script regtest-report.sh creates the file buildlogs/$version/index.html summarizing the results. Note: this reflects whether the toolchains could be built, not whether they work! Also note: running regtest-run.sh takes a LOT of cpu power, so it uses ssh to spawn build jobs on multiple machines. Read the script carefully before running it.

Contributed Patches

A few users of the crosstool scripts have submitted patches. I'm saving these in the 'contrib' directory until I have time to test them.
  • testsetup - my scripts which are handy when running test suite remotely
  • newlib, newlib2 - scripts to build newlib toolchains
  • crosstool-uclibc-0.28-rc5.patch to build uclibc toolchains (see below)
  • contrib/xtool-ro.patch lets you run with sources in a read-only directory.

uClibc

The script contrib/demo-uclibc.sh demonstrates how to patch an older version of crosstool to support uclibc. This script, with editing, can be used to build ARM7, PPC405, and maybe MIPS uclibc toolchains. A future version of crosstool will merge the patch.

Links

Patch repositories (handy if you are looking for a fix to a specific problem): There are many good general references for people building crosscompilers. Here is a somewhat outdated set: Here are a few posts about which combinations of versions work: Related Mailing lists (corrections welcome):


Portions copyright 2003, Ixia Communications
Portions copyright 2003, 2004, 2005 Google
Released under the GPL.
Last revision 21 July 2005 by dank@kegel.com
신고

'만드는 일 > 장치' 카테고리의 다른 글

한백전자 사이트  (0) 2006.09.15
한백전자의 EMPOS-II  (2) 2006.09.14
toolchain downloads  (0) 2006.09.14
crosstool-howto  (0) 2006.09.14
Toolchain for SMDK2410X targets HOWTO  (0) 2006.09.14
내장형시스템 실습 1주차  (0) 2006.09.14

Toolchain for SMDK2410X targets HOWTO

만드는 일/장치 2006.09.14 23:00 Posted by soulfree >동네청년<
Toolchain for SMDK2410X targets HOWTO

이 문서는
http://wiki.falinux.com/wiki.php/CROSSGCC3.3REZ-X5
http://lists.arm.linux.org.uk/pipermail/linux-arm/2003-August/005942.html
http://www.aleph1.co.uk/armlinux/docs/toolchain/toolchHOWTO.pdf
http://blog.naver.com/union_sy.do?Redirect=Log&logNo=80002185314
여기의 내용을 조합하여 정리 하였음을 알려 드립니다.

1) Pre-built Toolchains
binary 형태 또는 rpm(패키지로) 제공되는 cross compiler
1 Native Pre-built Compilers
2 Emdebian
3 LART
4 Compaq

Pre-built Toolchains은 단지 binary 파일을 정해둔 디렉토리로 옮기고 path만 설정하면 사용할 수 있다.
Pre-built Toolchains은 kernel header 파일 포함하여 만들어진 cross compiler이기 때문에 kernel에 영향을 받는 특정 프로그램은 이 cross compiler로 컴파일이 되더라도 board상에서 정확하게 동작 한다고 장담 할 수 없다.

2) Building the Toolchain
아래 설명되는 toolchain을 구축하는 방법은 http://lists.arm.linux.org.uk/pipermail/linux-arm/2003-August/005942.html 문서에 설명되어 있는 script 내용을 기초로 하여 작성 하였으며 The GNU Toolchain for ARM targets HOWTO (Wookey, Chris Rutter, Jeff Sutherland, Paul Webb) 문서를 참조 하였다.

1 필요한 소스 패키지
리눅스를 이용한 개발환경으로 선택했다면 크로스 컴파일 환경을 구축하여야 한다. 이 크로스 컴파일 환경에 포함되는 것은 다음과 같은 패키지가 필요로 하고 이 패키지들의 모음을 일반적으로 cross compile toolchain이라고도 한다.
1) binutils    : 어셈블러 및 로더 기타 툴 ( GNU )
2) glibc        : 크로스 컴파일 구축을 위한 라이브러리 및 일반 라이브러리
3) gcc        : 컴파일러  ( 시그너스 )
4) kernel    : 커널 소스
5) gdb        : 디버거

각각의 버전은 다음과 같다.
1) binutils    : binutils-2.14.90.0.6
2) glibc        : glibc-2.3.2
3) gcc        : gcc-3.3
4) kernel    : linux-2.4.18 (Linu@ SDK에서 제공하는 kernel)
5) gdb        : gdb-6.2.1

2 설치 전 작업
다운 받은 파일 목록을 정리하면
1) binutils-2.14.90.0.6.tar.gz
2) linux-2.4.19-x5-v04.tar.gz
3) gcc-3.3.tar.gz
4) glibc-2.3.2.tar.gz
5) glibc-linuxthreads-2.3.2.tar.gz
6) gdb-6.2.1.tar.gz

등 총 6개가 됩니다. 설치하려고 하는 linux에 다음 디렉토리를 만든다.
#mkdir -p project/toolchain
(이것은 사용하기 위하여 편의상 한 것이지 절대적인 것은 아님)
project/toolchain 에 다운 받은 파일을 가져다 놓는다.

  1. 설치 전 주의 사항 #
이제부터 진행하는 순서는 꼭! 지켜야 한다. 이유는 각 설치되는 패키지들의 의존 관계가 있기 때문이다. 설치는 root 권한으로 하여야 한다.

3 커널설치
여기서는 본격적인 커널 패치에 관련된 내용은 아니다. 단지 크로스 컴파일러를 만들기 위한 커널 설치이다. 크로스 컴파일러를 만들어 가는 과정에서 커널 헤더가 필요하기 때문에 하는 것이다.
kernel 설치에 관한 자세한 내용은 linuette SDK에서 제공하는 설치 가이드 문서를 확인한다.

여기서 기억해야 할 것은 이 커널 디렉토리의 위치이다. 우리는 커널의 위치로
/linuette/target/box/kernel로 설정한 상태이다.

4 GDB 패키지 설치
GDB는 크로스 컴파일 toolchain의 순서와 상관없이 언제든지 설치가 가능하다. 다음과 같이 설치하면 된다.
#tar zxvf gdb-6.2.1.tar.gz
이 명령을 수행하면 gdb-6.2.1 란 디렉토리가 생긴다. 이 디렉토리로 옮긴다.
#cd gdb-6.2.1
환경설정을 한다.
#./configure --target=arm-linux --build=i686-pc-linux-gnu --prefix=/usr
컴파일을 한다.

참조
-?target=arm-linux
target의 이름을 정하는 옵션
arm-linux
Linux/ARM을 지원하는 ELF로 컴파일
그 외에도 arm-linuxaout, arm-aout, arm-coff, arm-elf, arm-thumb 종류가 있다.
processor 종류에 따라
armv2
- ARM v2 architecture를 지원, 특히 26-bit mode code로 강제로 사용하게 한다.
armv3l, armv3b
- ARM v3 architecture (ARM610, ARM710), l -> little-endian b -> big-endian
armv4l, armv4b
- ARM v4 architecture (StrongARM, ARM7TDMI, ARM8, ARM9)
armv5l, armv5b
- ARM v5 architecture (XScale, ARM10)

#make
설치를 한다.
#make install
아마도 별 에러 없이 끝날 것이다.
제대로 설치되었다면 다음과 같은 명령을 치면 아래와 같이 나열된다.
#ls -al /usr/bin/arm-linux*
-rwxr-xr-x    1 root     root      5770628 10월 24 13:55 /usr/bin/arm-linux-gdb*
-rwxr-xr-x    1 root     root      1477505 10월 24 13:55 /usr/bin/arm-linux-run*

Binutils 패키지 설치 #
#tar zxvf binutils-2.14.90.0.6.tar.gz
#cd binutils-2.14.90.0.6
컴파일 환경을 설정한다.
#./configure --target=arm-linux --prefix=/usr --program-prefix=arm-linux-
컴파일 한다.
--program-prefix=arm-linux-
binutils의 파일을 생성할 때 arm-linux-가 붙게 된다.
#make
설치를 한다.
#make install
아마도 별 무리 없이 끝났을 것이다. 이 부분을 수행하고 나면 /usr/arm-linux 란 디렉토리가 생성된다.
#ls -al usr/arm-linux
합계 16
drwxr-xr-x    4 root     root         4096 10월 24 14:04 ./
drwxr-xr-x   19 root     root         4096 10월 24 14:04 ../
drwxr-xr-x    2 root     root         4096 10월 24 14:04 bin/
drwxr-xr-x    3 root     root         4096 10월 24 14:04 lib/

대부분의 실행파일은 /usr/bin에 복사 된다.
#ls /usr/bin/arm-linux-*
/usr/bin/arm-linux-addr2line*    /usr/bin/arm-linux-gdb*
/usr/bin/arm-linux-objdump*    /usr/bin/arm-linux-size*
/usr/bin/arm-linux-ar*        /usr/bin/arm-linux-ld*
/usr/bin/arm-linux-ranlib*    /usr/bin/arm-linux-strings*
/usr/bin/arm-linux-as*        /usr/bin/arm-linux-nm*
/usr/bin/arm-linux-readelf*    /usr/bin/arm-linux-strip*
/usr/bin/arm-linux-c++filt*    /usr/bin/arm-linux-objcopy* 
/usr/bin/arm-linux-run*

5 bootstrap compiler
gcc 초기 컴파일 단계에서 초기 컴파일 과정이 필요한 이유는 gcc cross compiler를 맨 처음 컴파일 할 때 필요한 환경이 제대로 갖춰져 있지 않기 때문이다. target 플랫폼과 관련 있는 각종 헤더 파일과 glibc 라이브러리가 없는 상황에서 gcc cross compiler를 어떻게 컴파일 하겠는가 (x86에서 x86용 gcc컴파일러를 컴파일 할 때는 헤더 파일과 glibc 라이브러리가 이미 있었다.)? 이런 문제를 극복하는 방법이 처음부터 완벽한 gcc교차 컴파일러를 만드는 대신 헤더 파일과 라이브러리를 준비할 수 있는 기능만 탑재한 gcc bootstrap compiler를 만드는 것이다.

이제 실제 크로스 컴파일러를 만든다. 압축을 푼다.
#tar zxvf gcc-3.3.tar.gz
몇 가지 파일을 수정한다.
#cd gcc-3.3
#perl -pi -e 's/^(TARGET_LIBGCC2_CFLAGS.*)/$1 -Dinhibit_libc -D__gthr_posix_h/' gcc/config/arm/t-linux
#echo 'T_CFLAGS = -Dinhibit_libc -D__gthr_posix_h' >> gcc/config/arm/t-linux

이것은 실제로 다음과 같이 파일을 직접 고치는 것과 동일 한 것이다.

==========[ 편집기를 사용했을때 ]==========
#cd gcc/config/arm/
#vi t-linux

TARGET_LIBGCC2_CFLAGS = -fomit-frame-pointer -fPIC    
수정 
TARGET_LIBGCC2_CFLAGS = -fomit-frame-pointer -fPIC -Dinhibit_libc
-D__gthr_posix_h

마지막 라인에 추가
T_CFLAGS = -Dinhibit_libc -D__gthr_posix_h
    
========================================

위에 편집 한 내용은 현재 bootstrap gcc를 만들고 있다는 사실을 컴파일러에 알려주기 위해 gcc-3.3/gcc/config/arm/t-linux 환경 설정 파일에 "T_CFLAGS= -Dinhibit_libc-D_gthr_posix_h"를 추가한다. (흔히 이를 inhibit_libc hack으로 부른다.) inhibit_libc는 libc를 사용하지 않겠다는 의미이고, _gthr_posix.h는 pthread 관련 헤더 파일을 찾지 않겠다는 의미이다.

이제 환경 설정과 컴파일을 수행한다.
#./configure --target=arm-linux --prefix=/usr
--with-headers=/linuette/target/box/kernel/include --disable-shared --disable-threads --enable-languages="c" --nfp --without-fp -?with-cpu=arm9
--with-softfloat-support=internal

s3c2410은 arm920t 임으로 ?with-cpu=arm9으로 줘야 하며 ?-with-headers 옵션의 kernel header의 경로는 자신이 target board에 올리는 kernel 경로에 맞게 작성한다.
thread 지원을 끄기 위해 disable-threads 옵션을 주며 enable-languages에 c를 지정한다. bootstrap gcc 컴파일 과정에서 c컴파일러 이외에 다른 컴파일러는 만들 수 없다.

컴파일을 한다.
#make
인스톨을 한다.
#make install
인스톨까지 정상적으로 수행 되었다. 확인을 위해서 다음과 같이 수행해 본다.
#ls /usr/bin/arm-linux-*
/usr/bin/arm-linux-addr2line*    /usr/bin/arm-linux-gcc*
/usr/bin/arm-linux-ld*        /usr/bin/arm-linux-readelf*
/usr/bin/arm-linux-ar*        /usr/bin/arm-linux-gcc-3.3*
/usr/bin/arm-linux-nm*        /usr/bin/arm-linux-run*
/usr/bin/arm-linux-as*        /usr/bin/arm-linux-gccbug*
/usr/bin/arm-linux-objcopy*    /usr/bin/arm-linux-size*
/usr/bin/arm-linux-c++filt*    /usr/bin/arm-linux-gcov*
/usr/bin/arm-linux-objdump*    /usr/bin/arm-linux-strings*
/usr/bin/arm-linux-cpp*        /usr/bin/arm-linux-gdb*
/usr/bin/arm-linux-ranlib*    /usr/bin/arm-linux-strip*

6 glibc 패키지 설치
가장 문제가 되는 glibc 패키지의 컴파일을 한다. 압축을 푼다.
#tar zxvf glibc-2.3.2.tar.gz
#tar -C glibc-2.3.2 -zxf glibc-linuxthreads-2.3.2.tar.gz
디렉토리를 이동한다.
#cd glibc-2.3.2
몇 가지를 수정한다.
./sysdeps/unix/sysv/linux/arm/sysdep.h 파일에서
    
161              : "a1", "memory");             \
의 내용을 
161              : "memory");               \
로 바꾼다.
     
./stdio-common/sscanf.c 파일에서 
    
30 sscanf (s, format)
31      const char *s;
32      const char *format;
    

    
30 sscanf (const char *s, const char *format, ...)
로 바꾼다.
    
./linuxthreads/sysdeps/unix/sysv/linux/arm/sysdep-cancel.h 파일에서 

37   ENTRY (name)                              \

37   ENTRY (name);                             \
로 바꾼다.

빌드할 디렉토리를 만든다.
#mkdir ../glibcbuild
#cd ../glibcbuild
환경 설정을 한다.
#CC=arm-linux-gcc ../glibc-2.3.2/configure arm-linux --build=i686-pc-linux-gnu
--with-headers=/linuette/target/box/kernel/include --enable-add-ons --enable-shared --prefix=/usr/arm-linux --with-cpu=arm9 --without-fp --enable-kernel=2.4.18

linuette에서 제공하는 kernel은 2.4.18이다.

컴파일을 한다.
#make
설치를 한다.
#make install


7 gcc 재설치
이제 마지막으로 gcc를 재설치 하여야 한다. 물론 옵션이 달라진다. 나중에 컴파일 할 때 라이브러리 의존성 문제가 생기므로 사전에 링크를 걸어 준다.
#cd /usr/arm-linux/lib
#ln -s ../../lib/* .

#sed -e '/*** BUG/d' /usr/arm-linux/lib/libc.so > /usr/arm-linux/lib/libc.so.new
#mv -f /usr/arm-linux/lib/libc.so.new -f /usr/arm-linux/lib/libc.so
#sed -e '/*** BUG/d' /usr/arm-linux/lib/libpthread.so >
/usr/arm-linux/lib/libpthread.so.new
#mv -f /usr/arm-linux/lib/libpthread.so.new -f /usr/arm-linux/lib/libpthread.so

#cd project/toolchain
기존에 내용을 모두 지운다.
#rm -rf gcc-3.3    
다시 압축을 푼다.
#tar zxvf gcc-3.3.tar.gz
#cd gcc-3.3
이제 환경 설정과 컴파일을 수행합니다. 환경을 설정한다.
#./configure --target=arm-linux --prefix=/usr --program-prefix=arm-linux-
--with-headers=/linuette/target/box/kernel/include/ --with-cpu=arm9
--with-softfloat-support=internal --enable-languages=c,c++ --nfp
컴파일을 한다.
#make
인스톨을 한다.
#make install
신고

'만드는 일 > 장치' 카테고리의 다른 글

한백전자 사이트  (0) 2006.09.15
한백전자의 EMPOS-II  (2) 2006.09.14
toolchain downloads  (0) 2006.09.14
crosstool-howto  (0) 2006.09.14
Toolchain for SMDK2410X targets HOWTO  (0) 2006.09.14
내장형시스템 실습 1주차  (0) 2006.09.14

내장형시스템 실습 1주차

만드는 일/장치 2006.09.14 21:12 Posted by soulfree >동네청년<
실험노트를 만드는 것으로 2분반 김제욱 조교와도 이야기가 되었습니다.
 
실험 주제별로 예비레포트를 노트에 작성해 와서 실험 끝나고
 
동작여부를 검사맞고, 어떻게 어떻게 했다는 내용을 작성해주고
 
조교의 도장이나 사인을 받으면 됩니다.
 
양식은 아래를 참고하면 됩니다.
 
다음주에 수행할 실습은 toolchain환경구축과 커널 컴파일 입니다.
 
toolchain이 뭐하는 것인지, 어떤걸로 구성되어 있는지, 어떻게 만드는
 
것인지 커널 컴파일은 어떻게 하는 것인지 나름대로 조사해 와서 그
 
지식을 바탕으로 실습시간에 적용해 보는 것으로 하면 됩니다.
 
원래 월요일에 올리기로 약속했는데 늦어져서 죄송합니다.
 

실습명 : 해당 주에 실습할 실습명

준비물 : 준비물이라고 해봤자 어떤 라이브러리가 필요한가, 어떤 프로그램이 필요한가 조사한 내용을 바탕으로 필요한 것들이 무엇인지 적어주면 됩니다.


예비 조사 내용

해당 실습할 내용에 대해 조사한 내용을 간결하게 적어주면 됩니다. 어떤 라이브러리, 프로그램이 필요한데 어떤 역할을 하는 것이며, 그것들을 바탕으로 실습을 어떻게 하면 된다라고 하는 실습 전에 예습의 성격이 큽니다.

결과내용

실습한 내용이 재대로 동작하는 지를 검사맞은 후에 자신이 실습중 수행한 내용을 적어놓으면 됩니다. 느낀점이라든가, 그런걸 추가해도 됩니다.

신고

'만드는 일 > 장치' 카테고리의 다른 글

한백전자 사이트  (0) 2006.09.15
한백전자의 EMPOS-II  (2) 2006.09.14
toolchain downloads  (0) 2006.09.14
crosstool-howto  (0) 2006.09.14
Toolchain for SMDK2410X targets HOWTO  (0) 2006.09.14
내장형시스템 실습 1주차  (0) 2006.09.14