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] |