Make the install directory and a few necessary subdirectories, if they don't already exist:
mkdir -p /home/fnf/gg mkdir -p /home/fnf/gg/bin mkdir -p /home/fnf/gg/lib mkdir -p /home/fnf/gg/m68k-amigaos
Strictly speaking it isn't necessary to make anything except /home/fnf/gg, since the subdirectories will normally be created as needed during the install procedure.
Pick a location for the root of the source tree. An example, used in these directions, is "/home/fnf/gg-src". This is where you will unpack all the Geek Gadgets source archives.
Make the directory if it doesn't already exist:
mkdir -p /home/fnf/gg-src
Pick a location for the build tree. This is a temporary work area in which you will build all the object files, executables, libraries, etc, that will be installed in your installation tree. It is possible to use the source tree as the build tree (building "in place") but that is not recommended. For one thing, you may want to remove the build tree once you've built and installed everything, and it is much easier to do that if you can just remove an entire directory and all subdirectories. For another thing, if you make changes to the source tree, it is easier to find out later what those changes are if your source tree is not cluttered with all the files created during the build, by simply diffing your source tree against the original.
An example, used in these directions, is "/home/fnf/gg-build". Make the directory if it doesn't already exist:
mkdir -p /home/fnf/gg-build
IMPORTANT: In order to successfully use separate source and build trees you must be using a "make" program that fully supports "VPATH". Some native "make" programs do not! The workaround is to use GNU make, so you may have to first build and install GNU make if you wish to keep the build and source trees separate. If this is not an option for you, then you can just do the builds in the source tree and forget about having a separate build tree.
During the build of the cross tools, you will need the standard ixemul header files. These are not used to build the cross tools, but rather used by the cross compiler when it is compiling some amiga objects, such as the libgcc.a runtime library that gets linked with the output of the cross compiler to make an Amiga executable. You will also need some other runtime files, such as an Amiga crt0.o and libc.a, from the ixemul library distribution. It is best if you get and install these files now, before starting to build the cross tools.
From the latest Geek Gadgets distribution, get the AmigaOS specific inline files (fd2inline-X.X-bin.lha), the AmigaOS specific libraries (libamiga-bin.lha), the libnix libraries (libnix-X.X-bin.lha) and the ixemul runtime files (ixemul-X.X-env-bin.lha, ixemul-X.X-inc-bin.lha).
If you expect to do Amiga specific development you will also need the AT/VISCorp include files, which are not available in the ftp Geek Gadgets distributions but are in the Geek Gadgets CD-ROM distributions (at-inc-bin.lha). Alternatively you can get these files later from some other source, such as one of the Native Developer Update Kits (NDUK) or from the AT developers CD-ROM. The AT/VISCorp include files are not necessary for building the cross environment, just for using it to build any AmigaOS specific programs.
Because these files are distributed in lha format in the Geek Gadgets distribution, the easiest way to get them to your cross machine is to extract all of these archives in a temporary directory on an Amiga and then make a "tar" archive which will be copied to your cross machine and unpacked there:
(on an Amiga) lha -mraxe x fd2inline-X.X-bin.lha lha -mraxe x libamiga-bin.lha lha -mraxe x libnix-X.X-bin.lha lha -mraxe x ixemul-X.X-env-bin.lha lha -mraxe x ixemul-X.X-inc-bin.lha
This will create subdirectories "bin", "guide", "include", "lib", and "man". Delete the bin and guide directories since you won't need their contents:
delete bin guide all force
Extract the AmigaOS include files from the optional at-inc-bin.lha archive from the Geek Gadgets CD-ROM (or skip this step if you don't have the CD-ROM), copy the files to the include directory, and delete the os-include directory that is created from the archive extraction:
lha -mraxe x at-inc-bin.lha copy os-include/#? include all delete os-include all force
Use the Amiga version of tar to pack the "include", "lib", and "man" directories into a tar archive, move the archive to the system on which you are installing the cross environment, and unarchive it in the appropriate subdirectory in the binary tree:
(on an Amiga) tar -cvf inclibman.tar include lib man delete include lib man all (on the cross host system) cd /home/fnf/gg/m68k-amigaos tar -xvf inclibman.tar rm inclibman.tar
Note that you can use any other method you like to get these files from your Amiga to the cross host system. The important thing is that they end up in the correct subdirectory in the installation tree, which is where the cross tools will look for them once the tools are built.
Get the binutils (assembler, linker, archiver, etc) distribution from the latest Geek Gadgets snapshot, for example binutils-2.7-src.tgz in pub/geekgadgets/current on ftp://ftp.ninemoons.com, and extract it in the source directory. It will create the subdirectory "fsf/binutils" and populate it with the binutils source files:
cd /home/fnf/gg-src tar -xvzf binutils-2.7-src.tgz
Check the Geek Gadgets updates directory (pub/geekgadgets/updates) on ftp://ftp.ninemoons.com for any patch files that need to be applied to the archive from the latest snapshot directory, and apply the patch (if necessary):
gzip -d binutils-961012-961111.diffs.gz (no such file, example only) cd fsf/binutils patch -p0 <../../binutils-961012-961111.diffs
Configure and build the binutils in the build tree. Note that the --prefix option should be set to the binary tree that you chose and it should be an absolute path (starts with a '/' character) not a relative path. Also, using a common cache file via the --cache-file option makes the configure go faster:
cd /home/fnf/gg-build mkdir binutils cd binutils /home/fnf/gg-src/fsf/binutils/configure -v --prefix=/home/fnf/gg --target=m68k-amigaos --cache-file=config.cache make
If everything builds OK, then install the binutils into the binary tree:
make install
Get the gcc distribution, for example gcc-2.7.2.1-src.tgz in pub/geekgadgets/current on ftp://ftp.ninemoons.com for example) from the latest Geek Gadgets snapshot and extract it in the source directory. It will create the subdirectory "fsf/gcc" and populate it with the gcc source files:
cd /home/fnf/gg-src tar -xvzf gcc-2.7.2.1-src.tgz
Check the Geek Gadgets updates directory (pub/geekgadgets/updates) on ftp://ftp.ninemoons.com for any patch files that need to be applied to the archive from the latest snapshot directory, and apply the patch (if necessary):
gzip -d gcc-961012-961111.diffs.gz (no such file, example only) cd fsf/gcc patch -p0 <../../gcc-961012-961111.diffs
Configure gcc in the build tree. Note that the --prefix option should be set to the binary tree that you chose:
cd /home/fnf/gg-build mkdir gcc cd gcc /home/fnf/gg-src/fsf/gcc/configure -v --prefix=/home/fnf/gg --target=m68k-amigaos
Because of some unresolved problems building a cross compiler, apply the following patch to the gcc Makefile after configuring and before building gcc.
============================================================================ --- Makefile.orig Mon Nov 11 18:51:20 1996 +++ Makefile Mon Nov 11 20:07:16 1996 @ -38,5 +38,5 @ # Selection of languages to be made. # This is overridden by configure. -LANGUAGES = c objective-c proto c++ +LANGUAGES = c c++ ALLOCA = @ -194,5 +194,5 @ # include files. # NOTE: local_prefix *should not* default from prefix. -local_prefix = /gg/local +local_prefix = $(prefix)/local # Directory in which to put host dependent programs and libraries exec_prefix = $(prefix) @ -273,5 +273,5 @ # libgcc1-test target (must also be overridable for a target) -LIBGCC1_TEST = libgcc1-test +LIBGCC1_TEST = # List of extra executables that should be compiled for this target machine @ -438,5 +438,5 @ SYSTEM_HEADER_DIR = /gg/include -OTHER_FIXINCLUDES_DIRS = /gg/os-include +OTHER_FIXINCLUDES_DIRS = # We don't need a libgcc1, it's all in ixemul.library @ -2437,5 +2437,5 @ # Remake the info files. -doc: info guide +doc: info # guide info: cpp.info gcc.info lang.info guide: cpp.guide gcc.guide lang.guide @ -2606,5 +2606,5 @ # broken is small. install-normal: install-common $(INSTALL_HEADERS) $(INSTALL_LIBGCC) \ - install-libobjc install-man install-info install-guide lang.install-normal install-driver + install-libobjc install-man install-info lang.install-normal install-driver # install-guide # Do nothing while making gcc with a cross-compiler. The person who ============================================================================
After the patch is applied, build and install gcc:
make make install
You might want to add the binary directory to your PATH variable:
PATH=/home/fnf/gg/bin:$PATH ; export PATH
An easy way to test the new cross tools is to configure and build one of the Geek Gadgets components in the cross environment, and then copy the executable back to an Amiga to see if it runs OK. I would suggest using the "brik" program:
cd /home/fnf/gg-src tar -xvzf brik-2.0-src.tgz cd /home/fnf/gg-build mkdir brik cd brik CC=m68k-amigaos-gcc /home/fnf/gg-src/contrib/brik/configure -v make CC=m68k-amigaos-gcc
On a 166 Mhz Pentium system running RedHat linux this build takes only 3 seconds while on an A4000 with 40 Mhz WarpEngine, it takes about 20 seconds. The executable should be about 12,800 bytes, but the exact size may vary depending upon a number of factors. Move the executable back to an Amiga and test it:
(on an Amiga) brik -Gvb brik
which should print something like:
# Whole file CRCs generated by Brik v2.0. Use "brik -C" to verify them. # CRC-32 filename # ------ -------- 2515614901b brik
Don't worry if the CRC is not the same as printed here.
If this works, you now have a functioning cross environment (or at least a cross compiler) that depending upon the model of your Amiga and the machine you are using as a cross development host, could easily be 20 times faster than a native compiler.
-Fred Fish @raisesections @raisesections
[Details under construction]
[Details under construction]
GDB is the GNU debugger. It is useable now with ixemul-based programs, though there are still some bugs to be worked out (it has problems when run in emacs because of the UNIX style pathnames it uses). Read the documentation for more information. The source archive will probably contain more amiga-specific information if it's needed.
If you start gdb with the -enforcer option, then the program you are debugging will automatically stop and drop into the debugger as soon as an Enforcer hit occurs. This is obviously very useful.
Any debugger that can handle the stabs format should work. If you know of any such, please report this to the mailing lists. See section 1.1 Mailing Lists.
[Details under construction]
Together with ixemul.trace, this program allows you to see every ixemul call (aka SnoopDOS for ixemul.library programs) and may be useful for debugging purposes.
Please refer to the ixemul documentation for further details. See section `Top' in The Ixemul Manual.
With the help of ixnet.library, ixemul.library now has full network support for both AmiTCP and AS225R2 compatible protocol stacks, and the AmiTCP-GCC SDK should not be used when compiling programmes using network functions.
Support for other protocol stacks can be added to ixnet.library as it becomes necessary.
See section 7.2.3 ixemul.
[Details under construction] Yes, GCC uses its own object file format. This means you aren't currently able to link to AmigaOS hunk format object files (standard). But hunk2aout (by Markus Wild) will do the conversion for you as described in See section 7.3.1.1 libamiga.a.
Why does GCC use its own object file format? It's really just a design decision that allows other gnu utilities to deal with these objects (for example, gdb, nm, objdump, and gas) without having to convert them to deal with AmigaOS hunks.
[Details under construction] Although it may sound irritating, it is in fact possible and sometimes useful to install several compiler versions side by side.
CLI> cd GNU:lib CLI> rename libgcc.a GNU:lib/gcc-lib/mc68000-cbm-amigados/2.7.0 (note: replace 2.7.0 with your GCC version) CLI> rename libb/libgcc.a GNU:lib/gcc-lib/mc68000-cbm-amigados/2.7.0/libb CLI> rename libm020/libgcc.a GNU:lib/gcc-lib/mc68000-cbm-amigados/2.7.0/libm020 CLI> cd GNU:bin CLI> rename gcc gcc-2.7.0 CLI> rename gccv gccv-2.7.0
Go to the first, previous, next, last section, table of contents.