This is the mail archive of the crossgcc@sources.redhat.com mailing list for the crossgcc project.
See the CrossGCC FAQ for lots more information.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
See detail howto about cross gcc for cross platform in the attachment. sincerely wang --- Wouter Andy <wouter51@hotmail.com> µÄÕýÎÄ£º> hello again... > > I followed the instructions on > http://crossgcc.billgatliff.com/ using my > cygwin as host and i686-pc-linux-gnu as target, > binutils compiled just fine, > but when i tried build all for the GCC 'bootstrap' > compiler i get following > error (from make.log): > > In file included from tm.h:7, > from > ../../gcc-3.0.3/gcc/config/i386/xm-i386.h:39, > from tconfig.h:3, > from > ../../gcc-3.0.3/gcc/libgcc2.c:36: > ../../gcc-3.0.3/gcc/config/i386/linux.h:236:20: > signal.h: No such file or > directory > ../../gcc-3.0.3/gcc/config/i386/linux.h:237:26: > sys/ucontext.h: No such file > or directory > make[2]: *** [libgcc/./_muldi3.o] Error 1 > make[2]: Leaving directory > `/i686-pc-linux/build-gcc/gcc' > make[1]: *** [libgcc.a] Error 2 > make[1]: Leaving directory > `/i686-pc-linux/build-gcc/gcc' > make: *** [all-gcc] Error 2 > > > what's the remedy on this, or am i doing something > wrong? > > Lots of thanks, Wouter > > _________________________________________________________________ > Chat on line met vrienden en probeer MSN Messenger > uit: > http://messenger.msn.nl > > > ------ > Want more information? See the CrossGCC FAQ, > http://www.objsw.com/CrossGCC/ > Want to unsubscribe? Send a note to > crossgcc-unsubscribe@sources.redhat.com >
%%howto-version: 1.0 %%title: Building Cygwin hosted Linux toolchain %%url: http://www.nanotech.wisc.edu/~khan/software/gnu-win32/ %%category: cygwin %%filename: cygwin-to-linux-cross-howto %%author: Mumit Khan This howto provides a roadmap to building a Linux development toolchain (ix86-pc-linux-gnu) hosted on Cygwin (ix86-pc-cygwin) platform. Shows how to build Linux 2.4.0 kernel as an example. And before you ask, no, I don't know why someone would want to do that ;-) TOC: - Background - Preliminaries - Build steps - Postscript Created: Tue Aug 3 17:34:57 CDT 1999 Last Modified: Thu Jan 25 11:10:11 CST 2001 Background: =========== When it comes to cross-compiling (the simple kind or the canadian kind), three terms are very important -- host, target and build. The host is the machine that the resulting toolchain will run on, the build is the machine that the resulting toolchain are being built on, and target is the machine that resulting toolchain will create binaries for. The most usual case is where host == build == target (eg., if you're using a Linux compiler on a Linux box that was created on a Linux box); in the case of most cross-compilers, host == build, target is different (eg., host and build could be say Linux and target could be say i686-pc-cygwin, so that when you compile/link on Linux box using this toolchain, you create binaries that will run on i686-pc-cygwin); in the case of building a canadian cross compiler, host, build and target may all be different (I'll refrain from expounding on this one, and leave it to your imagination). Ok, so let's say we have a PC running Win2k and Cygwin, and we want to able to build Linux binaries on that PC. Yuck, I know, but there are those who seem to want it, and I just did it to satisfy some perverse need to see if it could be done trivially. FYI, you can then easily build a Linux kernel on a Cygwin machine. CrossGCC folks use various schemes, and I personally find those too complicated, but do it my way mostly because I'm too lazy to read the instructions. Here're the basic steps: (Preliminaries) Decide on where you want to install and so on, (1) Gather all the source packages you need, move these over to the Cygwin host, (2) Get the Linux runtime from a Linux box and move that over as well, (3) Build and install Binutils, and finally (4) Build and install GCC. Postscript shows a simple example, and shows how to avoid GCC from always adding .exe to the executable name (if you want to avoid that, read that before step 3). Also shows how you can build the Linux 2.4.0 kernel on a Cygwin machine using your freshly built cross-development toolchain. The only complicated step is (2), but good news is that you *only* need to do this once. You only need to redo this when you want to upgrade glibc2 for the cross-compiler. For the purposes of this HOWTO, I've used the following packages: 1. Cygwin -- 1.3.6 (with all updates applied to date) 2. GCC -- 2.95.3 (part of Cygwin source distribution) 3. Binutils -- 2.11.2 (standard GNU distribution, you may however prefer to use whatever Linux/GNU folks use) 4. glibc2 -- 2.2.4 (with all updates applied to date) Specifying names for hosts and targets ====================================== The specifications used for hosts and targets in the `configure' script are based on a three-part naming scheme, but some short predefined aliases are also supported. The full naming scheme encodes three pieces of information in the following pattern: ARCHITECTURE-VENDOR-OS For example, you can use the alias `sun4' as a HOST argument or in a `--target=TARGET' option. The equivalent full name is `sparc-sun-sunos4'. The `configure' script accompanying GDB does not provide any query facility to list all supported host and target names or aliases. `configure' calls the Bourne shell script `config.sub' to map abbreviations to full names; you can read the script, if you wish, or you can use it to test your guesses on abbreviations--for example: % sh config.sub sun4 sparc-sun-sunos4.1.1 % sh config.sub sun3 m68k-sun-sunos4.1.1 % sh config.sub decstation mips-dec-ultrix4.2 % sh config.sub hp300bsd m68k-hp-bsd % sh config.sub i386v i386-pc-sysv % sh config.sub i786v Invalid configuration `i786v': machine `i786v' not recognized `config.sub' is also distributed in the source directory Preliminaries: ============== Scattered throughout this article are user commands that you'll type in, and I've used either ``cygwin$'' or ``linux$'' as the shell prompt to denote the host machine you're supposed to be on for that particular step. For the Cygwin host, let's say we'll be using the following (I'm using bash, so if you're using a csh/tcsh type shell, do the right thing): cygwin$ host=i686-pc-cygwin cygwin$ build=i686-pc-cygwin cygwin$ target=i686-pc-linux-gnu cygwin$ prefix=/usr/local/linux cygwin$ src_root=/usr/local/src/gnu Feel free to change $prefix and/or $src_root to match your environment, but please don't mess with $host, $build and $target. Do make sure that $src_root directory does exist. You don't have to set these shell variables of course, but it saves me some typing and saves you from my inevitable typos. You should also add $prefix/bin to your PATH, but you can wait till you have installed binutils for that (ie., end of Step 3). Step 1: ======= Gather all the source packages you need. The minimal set is the compiler sources, binary utilities. Let's say we get the following from a GNU mirror: gcc-2.95.3.tar.gz binutils-2.11.2.tar.gz Since we're building on a Cygwin host, the safe bet is to get a version of gcc-2.95.2 from the Cygwin distribution instead which may have some Cygwin specific fixes, which is what I use. See Cygwin home page at http://sources.redhat.com/cygwin/ to see how to download the GCC source package using the network "setup" utility (or just ftp it over from one the mirrors). At the time of this writing, the latest one is gcc-2.95.2-6. Download these on your Cygwin box and unpack: cygwin$ cd $src_root cygwin$ tar zxf /tmp/gcc-2.95.2.tar.gz cygwin$ tar zxf /tmp/binutils-2.10.1.tar.gz Step 2: ======= Gather the Linux target runtime. This is easier than having to build glibc2 using your cross-tools, believe me. Once you've gone through this process, you should be able to do without much trouble, provided you're familiar with glibc2 configuration and build process. Now comes the first slightly tricky job of deciding what the minimal set to get from a Linux box that will serve as our runtime. For the rest of this article, when I refer to GNU/Linux, I'm referring to a RedHat 6.2 installation, so please take note if you're using some other distribution. This at first would seem like a trivial task: ** On a Linux box now ** linux$ mkdir -p /tmp/linux-target-runtime linux$ cd /tmp/linux-target-runtime linux$ (cd /usr; tar cf - include) | tar xf - linux$ ln -s include sys-include [ Please don't ask why I add the sys-include symlink; if you do, I'll simply ask you look at GCC configuration files. In fact, we could have just renamed include to sys-include, but there are packages that get confused if the include directory is missing altogether. ] [ Also see note below on using --dereference tar option to avoid certain messy steps ] linux$ (cd /usr; tar cf - lib) | tar xf - linux$ (cd /; tar cf - lib) | tar xf - [ See below on avoiding copying the whole /lib and /usr/lib and only getting what you need. ] linux$ ls include lib sys-include But there's a kink. Let's start with the problem with the includes after we copied it over. If you look in /usr/include, you'll notice that there are two symbolic links that are rather important: /usr/include/linux --> ../src/linux/include/linux /usr/include/asm --> ../src/linux/include/asm Since we didn't use --dereference tar option, these remain as links, and copying the tree over will miss the actual files, ie., these will remain as dangling symbolic links. The ../src/linux points to /usr/src/linux, where your kernel headers and possibly the source tree is kept. So, that means that either you get your whole kernel header tree as well, maintaining the correct relative paths, or just copy those over instead of the symbolic link. But there's another slight kink -- you'll note that the symbolic link /usr/include/asm points to is itself a symbolic link -- points to asm-i386. Oh joy. /usr/src/linux/include/asm --> asm-i386 So, now we fix the links: linux$ cd /tmp/linux-target-runtime/include linux$ rm linux asm linux$ (cd /usr/src/linux/include; tar cf - linux asm-i386) | tar xf - linux$ ln -s asm-i386 asm Whew, done with the includes. Before you ask, yes, you could have just as easily used --dereference option to tar when copying the include tree and avoided this hassle, but I didn't want all the other linked include directories. Now, let's take a look at the library scenario: The following are the most basic, and absolutely needed in the lib directory: linux$ cd /tmp/linux-target-runtime linux$ ls -F lib Mcrt1.o gcrt1.o libc.a libc_stubs.a libdl.so.2@ crt1.o ld-2.1.3.so* libc.so libdl-2.1.3.so* libm-2.1.3.so* crti.o ld-linux.so.2@ libc.so.6@ libdl.so.1@ libm.a crtn.o libc-2.1.3.so* libc_nonshared.a libdl.so.1.9.5* libm.so.6@ [ '*' after the name denotes executable, and '@' denotes symlink ] Note that some of these files such as ld-linux.so and libc.so live in /lib, not in /usr/lib, and you'll have to copy those out. You can copy the whole tree of course. The only kink in the libraries is that you'll need to fix libc.so, which is just a linker script (and that's why it's only a few hundred bytes!). If you look inside, you'll see something like the following: linux$ cat lib/libc.so /* GNU ld script Use the shared library, but some functions are only in the static library, so try that secondarily. */ GROUP ( /lib/libc.so.6 /usr/lib/libc_nonshared.a ) Note the last line -- obviously these paths are not going to be the same on your Cygwin host, so both the paths need to changed to reflect your Cygwin installation. If you choose say /usr/local/linux as the prefix when building your Linux-targeted Cygwin-hosted toolchain on Cygwin, then change /lib to $prefix/i686-pc-linux-gnu/lib instead. Here's mine: cygwin$ cat /usr/local/linux/i686-pc-linux-gnu/lib/libc.so /* GNU ld script Use the shared library, but some functions are only in the static library, so try that secondarily. */ GROUP ( /usr/local/linux/i686-pc-linux-gnu/lib/libc.so.6 /usr/local/linux/i686-pc-linux-gnu/lib//libc_nonshared.a ) The /usr/local/linux/ in /usr/local/linux/i686-pc-linux-gnu comes from our $prefix setting and the i686-pc-linux-gnu comes from our $target setting in *Preliminaries*. So, let's package it up and send it over to Cygwin box. linux$ cd /tmp/linux-target-runtime linux$ tar -zcvf /tmp/linux-target-runtime.tar.gz . linux$ scp /tmp/linux-target-runtime.tar.gz user@cygwin_hostname:/tmp/ [ or use whatever method to copy it over to the cygwin box ] ** Back on the Cygwin box now ** Unpack the linux-target-runtime. cygwin$ mkdir -p $prefix/$target cygwin$ tar zxvf /tmp/linux-target-runtime.tar.gz cygwin$ ls include lib sys-include Ok, we're done with Step 1. It's painful, but you only do this once every few months, just like going to the dentist. It's smooth sailing from now on. Step 3: ======= Build and install binutils. Never build in the source tree, so I'll just arbitrarily pick $src_root/BUILD as the top build directory, under which I'll build both binutils and gcc. cygwin$ mkdir -p $src_root/BUILD/binutils cygwin$ cd $src_root/BUILD/binutils cygwin$ $src_root/binutils-2.11.2/configure \ --with-included-gettext \ --target=$target --host=$host --build=$build \ --prefix=$prefix -v 2>&1 |tee config.log cygwin$ make 2>&1 |tee make.log If all goes well, install. cygwin$ make install 2>&1 |tee install.log *IMPORTANT* Add $prefix/bin to your PATH Before going forward. cygwin$ export PATH=$PATH:$prefix/bin Check: cygwin$ $target-ld --version GNU ld 2.11.2 Copyright 2000 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License. This program has absolutely no warranty. Supported emulations: elf_i386 i386linux Done. Smooth sailing. Step 4: ======= Build and install GCC. cygwin$ mkdir -p $src_root/BUILD/gcc cygwin$ cd $src_root/BUILD/gcc cygwin$ $src_root/gcc-2.95.3/configure \ --enable-languages=c,c++ \ --with-gnu-as --with-gnu-ld \ --with-headers=/usr/local/i686-pc-linux-mdk81/include \ --with-libs=/usr/local/i686-pc-linux-mdk81/lib \ --with-included-gettext --enable-shared --enable-threads \ --target=$target --host=$host --build=$build \ --prefix=$prefix -v 2>&1 | tee config.log Feel free to change the arguments to --enable-languages, or leave it out altogether if you want to build all available languages. Also, do as you wish with --enable-shared and --enable-threads parameters. Don't mess with the rest. if gcc only cygwin$ make LANGUAGES=c all-gcc 2>&1 |tee make-c.log cygwin$ mv make.log make-c-only.log If all goes well, install. cygwin$ make LANGUAGES=c install-gcc 2>&1 |tee install-c.log cygwin$ mv install.log install-c-only.log if gcc g++ all cygwin$ make 2>&1 |tee make.log If all goes well, install. cygwin$ make install 2>&1 |tee install.log Postscript: =========== Now that you're run, you should be able to create binaries and ship those over to a Linux/GNU machine to run. If all goes well: $ cat > hello.c #include <stdio.h> int main() { printf("hello world\n"); return 0; } ^D $ $target-gcc -o hello hello.c $ ls -l hello* hello.c hello.exe Huh, why the .exe extension? Well, it has to do with gcc hosted on Cygwin, and you can always patch gcc sources to get rid of the automatic .exe addition. Just comment out the EXECUTABLE_SUFFIX macro in $src_root/gcc-2.95.3/gcc/config/i386/xm-cygwin.h and rebuild gcc. This is capable of building the Linux kernel. Of course, you'll be missing /sbin/depmod and /sbin/genksyms, but that's a different problem. You'll need a trivial patch to get around Cygwin limitation in command line argument length and a bug in mmap implementation, but other than that, it's the usual `make menuconfig; make dep; make clean; make bzImage' that everyone is used to. Do keep in mind that just because the kernel builds with gcc-2.95.2 does not mean that it's safe; see kernel documentation for more info. Build a gdb cygwin$ mkdir -p $src_root/BUILD/gdb cygwin$ cd $src_root/BUILD/gdb cygwin$ $src_root/gdb-5.0/configure \ --target=$target --host=$host --build=$build \ --prefix=$prefix -v 2>&1 |tee config.log cygwin$ make 2>&1 |tee make.log If all goes well, install. cygwin$ make install 2>&1 |tee install.log === Linux 2.4.0 kernel patch for Cygwin cross build: The following patch allows you to build the Linux 2.4.0 kernel on a Cygwin machine using a cross-compiler. Tested only on Win2k running Cygwin 1.1.7, gcc-2.95.2-6 and binutils-2.10.1. YMMV. The patch to <top>/Makefile avoids too long a command line error, and the patch to scripts/mkdep.c avoids a Cygwin mmap bug. Once patched, you can do the following: $ make CROSS_COMPILE=i686-pc-linux-gnu- dep $ make CROSS_COMPILE=i686-pc-linux-gnu- clean $ make CROSS_COMPILE=i686-pc-linux-gnu- bzImage and get a kernel. May even work! You can always set the CROSS_COMPILE variable in the <top>/Makefile and skip the CROSS_COMPILE setting when running make every time. 2001-01-24 Mumit Khan <khan@nanotech.wisc.edu> * Makefile (dep-files): Use xargs to reduce command line length. * scripts/mkdep.c (do_depend): Workaround for Cygwin mmap bug. --- Makefile.~1 Wed Jan 24 22:22:16 2001 +++ Makefile Wed Jan 24 22:23:19 2001 @@ -442,7 +442,7 @@ sums: dep-files: scripts/mkdep archdep include/linux/version.h scripts/mkdep init/*.c > .depend - scripts/mkdep `find $(FINDHPATH) -name SCCS -prune -o -follow -name \*.h ! -name modversions.h -print` > .hdepend + find $(FINDHPATH) -name SCCS -prune -o -follow -name \*.h ! -name modversions.h -print | xargs scripts/mkdep | cat > .hdepend $(MAKE) $(patsubst %,_sfdep_%,$(SUBDIRS)) _FASTDEP_ALL_SUB_DIRS="$(SUBDIRS)" ifdef CONFIG_MODVERSIONS $(MAKE) update-modverfile --- scripts/mkdep.c.~1 Wed Jan 24 17:41:19 2001 +++ scripts/mkdep.c Wed Jan 24 17:41:50 2001 @@ -471,7 +471,9 @@ cee_CONFIG_word: void do_depend(const char * filename, const char * command) { int mapsize; +#ifndef __CYGWIN__ int pagesizem1 = getpagesize()-1; +#endif int fd; struct stat st; char * map; @@ -490,7 +492,9 @@ void do_depend(const char * filename, co } mapsize = st.st_size; +#ifndef __CYGWIN__ mapsize = (mapsize+pagesizem1) & ~pagesizem1; +#endif map = mmap(NULL, mapsize, PROT_READ, MAP_PRIVATE, fd, 0); if ((long) map == -1) { perror("mkdep: mmap"); === End of Linux 2.4.0 kernel patch for Cygwin cross build. THE END ======= For more information on GNU Compiler Collection (GCC), see GCC home page: http://gcc.gnu.org/ For more information on Cygwin, see Cygnus's cygwin project page: http://www.cygwin.com/ For more information on Crossgcc, see: http://www.objsw.com/CrossGCC/ For more information on binutils, see: http://sources.redhat.com/binutils/ Latest version of this documentation, and other information related to GNU tools on various types of windows32 system, is available from my gnu-win32 page: http://www.nanotech.wisc.edu/~khan/software/gnu-win32/ Created: Tue Aug 3 17:34:57 CDT 1999 Last Modified: Thu Jan 25 11:10:11 CST 2001 Mumit Khan <khan@nanotech.wisc.edu> Good luck. %%end-howto
%%howto-version: 1.0 %%title: Building Cygwin hosted newlib-based target toolchain %%url: http://www.nanotech.wisc.edu/~khan/software/gnu-win32/ %%category: cygwin %%filename: cygwin-to-newlib-cross-howto %%author: Mumit Khan This howto provides a roadmap to building a newlib-based target development toolchain such as powerpc-eabi hosted on Cygwin (ix86-pc-cygwin) platform. Even though I am using Cygwin as the host in this HOWTO, the information here is just as applicable to other hosts. TOC: - Background - Preliminaries - Build steps - Postscript Created: Thu Jan 25 11:10:11 CST 2001 Last Modified: Thu Jan 25 15:05:13 CST 2001 Background: =========== When it comes to cross-compiling (the simple kind or the canadian kind), three terms are very important -- host, target and build. The host is the machine that the resulting toolchain will run on, the build is the machine that the resulting toolchain are being built on, and target is the machine that resulting toolchain will create binaries for. The most usual case is where host == build == target (eg., if you're using a Linux compiler on a Linux box that was created on a Linux box); in the case of most cross-compilers, host == build, target is different (eg., host and build could be say Linux and target could be say i686-pc-cygwin, so that when you compile/link on Linux box using this toolchain, you create binaries that will run on i686-pc-cygwin); in the case of building a canadian cross compiler, host, build and target may all be different (I'll refrain from expounding on this one, and leave it to your imagination). Ok, so let's say we have a PC running Win2k and Cygwin, and we want to able to build powerpc-eabi binaries on that PC. The runtime library for that target is newlib, which should be quite known to those who are into this sort of thing. This HOWTO is applicable to all supported GCC targets that use newlib as the runtime library, and I just happen to be using powerpc-eabi as an example. CrossGCC folks use various schemes, and I personally find those too complicated, but do it my way mostly because I'm too lazy to read the instructions. Here're the basic steps: (Preliminaries) Decide on where you want to install and so on, (1) Gather all the source packages you need, move these over to the Cygwin host, (2) Build and install Binutils, (3) Build and install *just* the C compiler in GCC, then (4) use the C compiler just installed to build and install newlib, and finally (5) go back and build the rest of the compilers and language support runtimes in GCC and install those as well. Postscript shows a simple example, and shows how to avoid GCC from always adding .exe to the executable name (if you want to avoid that, read that before step 3). There is one thing to note here -- you will run into the term "single tree" build, which means that all the required components are in one tree, and set up so that you can simply do a `configure', followed by a `make', and you're good to go without having to go through the steps I have outlined here. However, unless you already have a tested and verified single-tree configuration such as GNUPro formerly from Cygnus Solutions and now from RedHat if you are a customer, you are much better off building each piece individually. One might think that building a single tree out of all the individual pieces is trivial -- just unpack on top of each other, and then combine all the common pieces. Try that with different versions of bfd included in binutils and in gdb, and you'll soon run into a disaster. Stick with multiple separate packages, and you will not regret the extra keystrokes. It is after all scriptable, so keystrokes go down to just a few. For the purposes of this HOWTO, I've used the following packages: 1. Cygwin -- 1.1.7 (with all updates applied to date) 2. GCC -- 2.95.2-6 (part of Cygwin source distribution) 3. Binutils -- 2.10.1 (standard GNU distribution) 4. newlib -- 1.9.0 (http://sources.redhat.com/newlib/) Specifying names for hosts and targets ====================================== The specifications used for hosts and targets in the `configure' script are based on a three-part naming scheme, but some short predefined aliases are also supported. The full naming scheme encodes three pieces of information in the following pattern: ARCHITECTURE-VENDOR-OS For example, you can use the alias `sun4' as a HOST argument or in a `--target=TARGET' option. The equivalent full name is `sparc-sun-sunos4'. The `configure' script accompanying GDB does not provide any query facility to list all supported host and target names or aliases. `configure' calls the Bourne shell script `config.sub' to map abbreviations to full names; you can read the script, if you wish, or you can use it to test your guesses on abbreviations--for example: % sh config.sub sun4 sparc-sun-sunos4.1.1 % sh config.sub sun3 m68k-sun-sunos4.1.1 % sh config.sub decstation mips-dec-ultrix4.2 % sh config.sub hp300bsd m68k-hp-bsd % sh config.sub i386v i386-pc-sysv % sh config.sub i786v Invalid configuration `i786v': machine `i786v' not recognized `config.sub' is also distributed in the source directory Preliminaries: ============== Scattered throughout this article are user commands that you'll type in, and I've used ``cygwin$'' as the shell prompt. Let's say we'll be using the following (I'm using bash, so if you're using a csh/tcsh type shell, do the right thing): cygwin$ host=i686-pc-cygwin cygwin$ build=i686-pc-cygwin cygwin$ target=powerpc-eabi cygwin$ prefix=/usr/local/powerpc cygwin$ src_root=/usr/local/src/gnu Feel free to change $prefix and/or $src_root to match your environment, but please don't mess with $host, $build and $target. Do make sure that $src_root directory does exist. You don't have to set these shell variables of course, but it saves me some typing and saves you from my inevitable typos. You should also add $prefix/bin to your PATH, but you can wait till you have installed binutils for that (ie., end of Step 2). Step 1: ======= Gather all the source packages you need. The minimal set is the compiler sources, binary utilities. Let's say we get the following from a GNU or RedHat sourceware mirror: gcc-2.95.2.tar.gz binutils-2.10.1.tar.gz newlib-1.9.0.tar.gz Since we're building on a Cygwin host, the safe bet is to get a version of gcc-2.95.2 from the Cygwin distribution instead which may have some Cygwin specific fixes, which is what I use. See Cygwin home page at http://sources.redhat.com/cygwin/ to see how to download the GCC source package using the network "setup" utility (or just ftp it over from one the mirrors). At the time of this writing, the latest one is gcc-2.95.2-6. Download these on your Cygwin box and unpack: cygwin$ cd $src_root cygwin$ tar zxf /tmp/gcc-2.95.2.tar.gz cygwin$ tar zxf /tmp/binutils-2.10.1.tar.gz cygwin$ tar zxf /tmp/newlib-1.9.0.tar.gz Step 2: ======= Build and install binutils. Never build in the source tree, so I'll just arbitrarily pick $src_root/BUILD as the top build directory, under which I'll build both binutils and gcc. cygwin$ mkdir -p $src_root/BUILD/binutils cygwin$ cd $src_root/BUILD/binutils cygwin$ $src_root/binutils-2.11.2/configure \ --with-included-gettext \ --target=$target --host=$host --build=$build \ --prefix=$prefix -v cygwin$ make > make.log 2>&1 If all goes well, install. cygwin$ make install > install.log 2>&1 *IMPORTANT* Add $prefix/bin to your PATH Before going forward. cygwin$ export PATH=$PATH:$prefix/bin Check: cygwin$ $target-ld --version GNU ld 2.10.1 Copyright 2000 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License. This program has absolutely no warranty. Supported emulations: elf32ppc Done. Step 3: ======= Build and install *just the C compiler* from GCC. cygwin$ mkdir -p $src_root/BUILD/gcc cygwin$ cd $src_root/BUILD/gcc cygwin$ $src_root/gcc-2.95.3/configure \ --enable-languages=c,c++ \ --with-included-gettext --enable-shared --enable-threads \ --target=$target --host=$host --build=$build \ --with-newlib \ --prefix=$prefix -v Feel free to change the arguments to --enable-languages, or leave it out altogether if you want to build all available languages. Also, do as you wish with --enable-shared and --enable-threads parameters. Don't mess with the rest. The --with-newlib is critical since it tells the compiler not to try to include stdlib.h and unistd.h when building libgcc.a, which is built as part of the core C compiler build (short answer: the configure script defines the inhibit_libc macro, which in turn guards against certain target includes in gcc/libgcc2.c file). Now, please note that we're specifically only building the C compiler and just that. cygwin$ make LANGUAGES=c all-gcc > make.log 2>&1 cygwin$ mv make.log make-c-only.log If all goes well, install. cygwin$ make LANGUAGES=c install-gcc > install.log 2>&1 cygwin$ mv install.log install-c-only.log Now you can build C code with the installed compiler. You could have also built the C++ compiler as well, but since we don't need that for building newlib, let's hold on till we're done with step 4. Step 4: ======= Build and install newlib: cygwin$ mkdir -p $src_root/BUILD/newlib cygwin$ cd $src_root/BUILD/newlib cygwin$ $src_root/newlib-1.9.0/configure \ --target=$target --host=$host --build=$build \ --prefix=$prefix -v cygwin$ make > make.log 2>&1 If all goes well, install. cygwin$ make install > install.log 2>&1 Now you have the target environment in place, and you can build the rest of the world. Step 5: ======= Build and install the rest of the GCC compilers and language runtime and/or support libraries. cygwin$ cd $src_root/BUILD/gcc cygwin$ make > make.log 2>&1 cygwin$ make install > install.log 2>&1 Postscript: =========== Now that you're run, you should be able to create $target target binaries. If all goes well: $ cat > hello.c #include <stdio.h> int main() { printf("hello world\n"); return 0; } ^D $ $target-gcc -o hello hello.c $ ls -l hello* hello.c hello.exe [ btw, since our example target is powerpc-eabi, you may have to supply at least one -m<xx> parameter, such as -msim, for this to work ] Huh, why the .exe extension? Well, it has to do with gcc hosted on Cygwin, and you can always patch gcc sources to get rid of the automatic .exe addition. Just comment out the EXECUTABLE_SUFFIX macro in $src_root/gcc-2.95.2-6/gcc/config/i386/xm-cygwin.h and rebuild gcc. Incidentally, the whole business of first building and installing only the C compiler part in GCC is only needed if you don't have the target environment, newlib in this case, fully installed. After the first time, all that is unnecessary of course. If you're building gdb-5.0 as well (which includes the ppc simulator by the way), you may need to comment out the declaration for strsignal in gdb-5.0/gdb/defs.h to get it to build. Otherwise, the declaration will not match the one in newlib (newlib's one returns a const char *, whereas gdb's declaration omits the const). THE END ======= For more information on GNU Compiler Collection (GCC), see GCC home page: http://gcc.gnu.org/ For more information on Cygwin, see Cygnus's cygwin project page: http://www.cygwin.com/ For more information on Crossgcc, see: http://www.objsw.com/CrossGCC/ For more information on binutils, see: http://sources.redhat.com/binutils/ Latest version of this documentation, and other information related to GNU tools on various types of windows32 system, is available from my gnu-win32 page: http://www.nanotech.wisc.edu/~khan/software/gnu-win32/ Created: Thu Jan 25 11:10:11 CST 2001 Last Modified: Thu Jan 25 15:05:13 CST 2001 Mumit Khan <khan@nanotech.wisc.edu> Good luck. %%end-howto
------ Want more information? See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/ Want to unsubscribe? Send a note to crossgcc-unsubscribe@sources.redhat.com
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |