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] |
Hello, Thanks for the howto. But i got one problem: i am currently unable to get the necessary libs and includes from glibc on my linux partition, and if i could: for some reason it doesn't want to mount my ntfs partition rw, it always mounts it read-only. how can i first make the bootstrap compiler and then cross-compile the glibc? or is that impossible? everytime i tried till now resulted in errors can't find <ucontext.h> and <signal.h> Thanks, Wouter >From: Wales Wang <wormwang@yahoo.com> >To: Wouter Andy <wouter51@hotmail.com> >CC: crossgcc@sourceware.cygnus.com >Subject: Re: Crosscompiler for i686-pc-linux from cygwin >Date: Wed, 23 Jan 2002 13:14:19 +0800 (CST) > >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 _________________________________________________________________ Meld je aan bij de grootste e-mailservice wereldwijd met MSN Hotmail: http://www.hotmail.com/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
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |