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]

Re: Crosscompiler for i686-pc-linux from cygwin


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]