Go to the first, previous, next, last section, table of contents.


6. Usage

This chapter describes the usage of various parts of Geek Gadgets.

6.1 Initial problems

This section tries to cope with those problems known to arise for almost everyone starting to use Geek Gadgets. If you stumble about other things, please discuss them with the Geek Gadgets mailing lists. See section 1.1 Mailing Lists.

6.1.1 Stack size

Many Geek Gadgets tools require large amounts of stack space. Some of them have been compiled to automatically grow the stack as necessary, but the work to build all of them with automatic stack expansion is not yet complete. Thus you need to take care to set an appropriate amount of stack. One way to do this is to add a line like:

stack 200000

to your S:User-Startup file. There are various opinions about what the minimum stack size should be. You could get away with as little as 50K in some circumstances, or need over 500K in others. Random crashes, irreproducible behavior, machine lockups, and other such problems are typical symptoms of setting the stack too low.

An alternate way to specify a larger stack on a per program base is the use of ixstack. Starting with ixemul-44.0, ixstack can be used on a program to set the stack allocated by ixemul.library when starting a new section 6.2.3 ixemul program.

Recommended stack sizes for use with ixstack:

pdksh
50KB, upto 128KB if using a very large `config.cache' file like the one from `GG:etc/'
GCC
is compiled with `-mstackextend' now, but used to require from 50KB to 800KB depending on the source file
GNUEmacs
40KB, some people seem to need more
man
32KB recommended for man since `manutils-2.x'. man can call groff, see below
groff
64KB recommended by Rask Ingemann Lambertsen rask@kampsax.dtu.dk
sed
128KB recommended by Lars Hecking lhecking@nmrc.ucc.ie otherwise some configure scripts crash the machine

Please send suggestions about stack sizes to Fred Fish fnf@ninemoons.com

6.1.2 Hello World

OK, what about a nice Hello World ?

#include <stdio.h>

main()
{
	printf("Hello World!\n");
}

This was pretty simple ;-) Now we have to compile it. There's a lot of options in GCC but the simplest way to compile this would be:

CLI> gcc -o hello hello.c

Simple?

Here's more options.

Target processor for Motorola family: You can compile plain 68000 code, 68020, 68030, 68040, 68881 (have a look at GCC documentation, either in info or AmigaGuide format, chapter Invoking GCC/SubModel Options/M680X0 Options for Motorola specific compilation flags).

CLI> gcc -m68020 -m68881 -o hello hello.c

This will compile your programs using 68020 code and direct calls to math-processor, and will link with accelerated libraries, located in GCC:lib/lib020.

Optimization: Either you don't want optimization, or you can provide -O, which will optimize your code, or if you really want top optimization, use -O2 flag (for more discussion about optimization, read info or AmigaGuide doc chapter Invoking GCC/Optimize Options). There's now even a -O3 optimization option, which will go even further.

CLI> gcc -O2 -o hello hello.c

You'll never have a "Hello World" program running so fast ;-)

Code generation: Perhaps you want to generate resident programs. Flag is -resident, at compile and link stage.

CLI> gcc -resident -o hello hello.c

Of course you can mix all options, resulting in:

CLI> gcc -O2 -m68020 -m68881 -resident -o hello hello.c

This will make a 68020+68881 executable highly optimized and resident.

IMPORTANT: If you only use AmigaOS functions or you don't want to use ixemul for philosophical reasons, you can get rid of ixemul.library with:

CLI> gcc -noixemul -o foobar foobar.c

provided you have libnix distribution (included with 2.6.0 and up distributions).

6.1.3 Hello Amigaworld

OK, what about another nice Hello World using AmigaOS?

/*  Compile this example with
	gcc -noixemul -o HelloWorld HelloWorld.c
*/
#include <stdlib.h>
#include <intuition/intuition.h>
#include <proto/intuition.h>

int main(int argc, char *argv[])
{
	struct EasyStruct es;

	es.es_StructSize = sizeof(es);
	es.es_Flags = 0;
	es.es_Title = "Message";
	es.es_TextFormat = "Hello, world!";
	es.es_GadgetFormat = "Ok";
	EasyRequest(NULL, &es, NULL, IntuitionBase);
	exit(0);
}

Some notes:

6.1.4 Ixemul vs. Libnix

Starting with 2.6.1 version of AmigaOS GCC, two C libraries are provided.

First one is using ixemul.library Amiga shared-library at run-time. This library makes it possible to easily convert Unix(tm) programs to AmigaOS, and made GCC possible on AmigaOS, for example. See section 6.2.3 ixemul.

Second one is an ANSI-C compliant library which is better suited for AmigaOS specific development, thus not using any Unix specific routines. Libnix is a static (i.e. link) library for GCC 2.3.3 or above. It's not a replacement for ixemul.library (though it's possible to recompile most of the GCC environment with libnix) but a good thing for Amiga specific development on GCC. See section 6.2.6 libnix.

Note that you can develop AmigaOS specific programs with ixemul.library, but at the cost of an extra 200 kB of memory taken by shared library.

To cut it short:

Use ixemul.library for porting Un*x programs, libnix for compiling amiga-only programs and gcc becomes one of the best Amiga compilers.

6.1.5 Memory shortage

Some Geek Gadgets tools (i.e. gcc) are often (but not always) memory hungry, a few tricks to save memory can make life easier:

6.1.6 Storage shortage

A Geek Gadgets installation may well need lots of space on your storage media, a few tricks to save storage can make life easier:

6.1.7 SAS/C => GNU/C

It is possible to link object files that were created by different conpilers, specifically GNU/C and SAS/C, as follows:

One problem with this approach would be with floating point code and with integer multiplication/division. To surround this problem you can either compile your SAS/C programs with CPU=68020 (or higher) and MATH=68881 to make SAS/C produce inline code. Or you will have to grab the necessary modules from the SAS/C libraries and convert them to aout object format as well.

6.2 Package topics

This section summarizes informations concerning specific programs or packages.

Of course, almost every package comes with a documentation of its own, which is the primary source of information. But there's often the need to give some extra informations which doesn't fit into this documentation for various reasons, such as:

6.2.1 gcc

Please refer to the gcc-amigaos documentation for further details on the AmigaOS specific features of gcc. See section `Top' in The GCC-AmigaOS Manual.

Please refer to the gcc documentation for further details on gcc. See section `Top' in The GCC Manual.

6.2.2 gnat

If you download a copy of the Gnat archive in .tgz format, you must take into consideration the problems with the datestamps. The datestamps allow the ada compiler to see if a package has been modified. The compiler will recompile any package if it has been modified.

If you just unpack the archive, the datestamps on the ada packages will be wrong and you will need a lot of memory to recompile the entire set of packages (> 8MB). To avoid this you must set the timezone to the correct offset.

If you downloaded the archive from ftp://ftp.ninemoons.com/pub/geekgadgets or one of its mirrors, you will need to use the MST timezone. If you downloaded the recent archive from ftp://ftp.idiom.com/users/ocremel/, you will need to use the PST8 timezone. The latter version of Gnat has not been included into Geek Gadgets yet, and thus the version of GCC that is installed as part of Gnat is different to the version of GCC from Geek Gadgets in that it will not find the linker ld if executed from within a normal Amiga Shell.

In the Amiga shell type the following:

To decompress gnat with the datestamps correct...

	copy gnat.tgz to gg:
	setenv TZ PST8 or MST
	ixtimezone -get-offset
	tar -xzvpf gnat.tgz

Reset the timezone for your machine...

	setenv TZ (local timezone)
	ixtimezone -get-offset

The following environment variables need to be added to the GG-startup script in gg:sys/s/ for Gnat to work properly:

	setenv ADA_INLUDE_PATH /gg/adainclude
	setenv ADA_OBJECTS_PATH /gg/lib/gcc-lib/m68k-amigaos/2.7.2.1/adalib

You may have more than one path in these environment variables. If you do, however, separate them with a colon in the normal unix fashion.

Test the compiler with the following code:

with Text_Io ;
use Text_Io ;

procedure Hello is

begin

  Put ( "Hello! This is your computer speaking." ) ;

end Hello ;

Run the compiler like this (NOTE: gnat must be run from within a unix shell, This will avoid an EMT trap error):

2.Work:Downloads/ada>sh
$gnatmake hello
$hello
Hello! This is your computer speaking.
$

6.2.3 ixemul

This library was developed by Markus Wild when originally started porting GCC (up to version 2.3.3). It is a shared library that emulates a lot of Un*x functions, making life a lot easier for folks porting GNU utilities and such. Unfortunately, it is fairly resource hungry by Amiga standards, and has caused not a little irritation among Amiga users. By default, programs compiled by GCC open ixemul.library, so if you want to avoid it, you'll have to use `-noixemul' on the command line (see below in Amiga specific extensions and/or coding with libnix) and link to one of the libraries below.

For an introduction and a comparison, see section 6.1.4 Ixemul vs. Libnix.

You can use the ixprefs program to set various options of ixemul.library. Please refer to the ixprefs documentation for further details. See section `Top' in The Ixprefs Manual.

Please refer to the ixemul documentation for further details. See section `Top' in The Ixemul Manual.

6.2.4 java

The Java support in Geek Gadgets is still under development. Especially there is not much documentation available to the date of this writing. This is partially owed to the fast evolution of the Java language standard.

There are two important packages dealing with Java:

Please refer to the GG-java-FAQ for further informations. See section `Top' in The GG-java-FAQ.

6.2.5 ld

Starting from 2.5.8 release, ld behaviour over symbols has changed. Default is now to strip all symbols from generated executable ONLY if environment variable LDSTRIP is set (to whatever you want). Otherwise, '-s' flag will strip symbols, as usual. Also packing of uninitialized data will be done automatically if LDSHORTDATA is set (to whatever you want). Ld also knows about -chip and -fast keywords, gcc will soon handle them directly. Ld is using now flavours, which are generated depending on gcc flags:

Gcc option Flavor passed to ld -m68020 -fl libm020 -noixemul -fl libnix -resident -fl libb

Thus ld when searching for libraries, adds those flavours to the library search path, in alphabetical order. Normal search path is /gnu/lib, and if for example you want to compile using -m68020 -noixemul ld will look for libgcc.a in: /gnu/lib/libm020/libnix first, then it will reduce flavours, one by one, if it can't find required library in flavour's expanded path. This means that it will try to find libgcc.a in: /gnu/lib/libm020 and in /gnu/lib/. Because libgcc.a exists in /gnu/lib/libm020, ld will take this one.

There is as for now 8 possibilities:

Flavors Search path libb libm020 libnix 0 0 0 /gnu/lib/ normal 0 0 1 /gnu/lib/libnix/ non-ixemul 0 1 0 /gnu/lib/libm020/ normal 68020 0 1 1 /gnu/lib/libm020/libnix/ non-ixemul 68020 1 0 0 /gnu/lib/libb/ baserel 1 0 1 /gnu/lib/libb/libnix/ baserel non-ixemul 1 1 0 /gnu/lib/libb/libm020/ baserel 68020 1 1 1 /gnu/lib/libb/libm020/libnix/ baserel 68020 non-ix

Using this approach makes adding flavours pretty easy, if someone wants for example to add 68881 libraries, a new flavour will have to be created, libm881, and thus the maximum flavour search path level would be: /gnu/lib/libb/libm020/libm881/libnix, which can be translated to English as: "I want a base-relative library compiled using Motorola 68020 and coprocessor 68881, not using ixemul.library".

6.2.6 libnix

This is a standard link library to replace the functionality of ixemul.library. Make sure you link to it if you use the `-noixemul' command line option for gcc.

Libnix, a static (i.e. link) library for gcc 2.3.3 or above. It's not a replacement for ixemul.library (though it's possible to recompile most of the gcc environment with libnix) but a good thing for amiga specific development on gcc:

For an introduction and a comparison, see section 6.1.4 Ixemul vs. Libnix.

Please refer to the libnix documentation for further details. See section `Top' in The Libnix Manual.

6.2.7 tar

Using tar to transfer files from a Unix machine to the Amiga is quite useful but may cause some trouble, especially when used in multi-volume mode with disks. This section gives a short overview how to use tar in this case and lists a few possible problems and describes the solutions to solve them.

If the files or the archive is larger than what will fit on a single disk we use tars multivolume option (--multi-volume or M) to spread the archive on several disks. We won't have to split the archive manually, tar will handle it.

For example, to spread the `egcs-2.90.18-base.tgz' archive (experimental gcc) on the Unix side on several disks we use: (the archive is about ~9.5 MB)

tar cvMf /dev/fd0 egcs-2.90.18-base.tgz

(the correct devicename to access the disk drive (here /dev/fd0) depends on your Unix system (here Sun Solaris) )

If the first disk is full tar prompts for the next disk:

Prepare volume #2 for /dev/fd0 and hit return:

And so on.... it will take 7 hd disks for the complete egcs archive.

Now we try to extract the archive on the Amiga side.

First we will need a special handler, either the device-handler or the rawdisk-handler. You will find them on Aminet.

If we use the rawdisk-handler and mount it as fd0:, we use

unix style path names: tar xvMf /fd0
amiga style path names: tar xvMf fd0: --force-local

or if we have the device-handler, we use

unix style path names: tar xvMf /DEV/pc0 (uppercase DEV!)
amiga style path names: tar xvMf dev:pc0 --force-local

to extract the archive.

For Amiga style pathnames, ie. with colons, we must use the --force-local option because tar uses the colon to recognize remote archives and this interferes with the amiga style path.

Using Unix style pathnames with the device-handler we must use an uppercase DEV. Here is a snip from a posting to the gg mailing list explaining why:

------------------------------------------------------------------- Fixed a bug in handling volumes/devices named "dev:". Ixemul handles the volume /dev/ specially (e.g., /dev/console is translated to console:) and that interfered with the handling of the DEV: device or any volume named DEV:. To circumvent the /dev handling you can now use "dev:" instead of "/dev" or write "DEV" instead of "dev" (in other words, the open() function tests for the string "/dev/" in a case-sensitive way). -------------------------------------------------------------------

If we could succesfully extract our archives with the above information, great, we didn't have any problems. ;-)

Problem 1: hd disk detection

We may have a problem with the device-handler and hd disks because it doesn't automatically recognize hd disks. By default, ie. if we just use /DEV/pc0 it will only read 736768 bytes from a hd disk.

To recognize hd disks we use:

unix style path names: tar xvMf /DEV/pc0/HICYL=159
amiga style path names: tar xvMf dev:pc0/HICYL=159 --force-local

The rawdisk-handler autodetects hd disks.

Problem 2: This volume is out of sequence

There is another problem when tar doesn't except the second archive disk and prints a message like this:

tar: This volume is out of sequence
Prepare volume #2 for /fd0 and hit return:

If we are sure that it is the correct disk the problem is most certainly that tar did read a wrong number of bytes from the first disk. But we can correct this.

By default, ie. with

tar xvMf /fd0 or tar xvMf /DEV/pc0/HICYL=159

both handler read 1474048 bytes from a hd disk.

With

tar vtf /fd0 or tar vtf /DEV/pc0

on the second disk we can find out the correct value of bytes tar should have read.

For example: tar vtf on the second disk of the egcs archive gives: (Note: minor fields are missing so it fits on a single line)

M--------- 8539216 egcs-2.90.18-base.tgz--Continued at byte 1453568--

The first number is the number of bytes to go until the end of the archive. The second number is the offset for the part on this disk from the beginning of the file.

As we can see 1453568 is not equal to 1474048 and therefore tar doesn't except the second disk. In this case tar had read 20k to much.

Fortunately we can make tar read the correct number of bytes.

First we devide the offset with 512, that gives the number of 512-blocks and add 1 to it. In the example we get: 1453568 / 512 = 2839, 2839 + 1 = 2840.

If we use the rawdisk-handler we pass the corrected 512-blocks number to tars --block-size option, ie.

tar vxbMf 2840 /fd0

This will make tar read only 1453568 bytes and not 1474048 bytes from the disks and it will except the following disk without complaining about "This volume is out of sequence" anymore.

Using the device-handler we can directly tell the handler how many bytes it should read:

tar vxMf /DEV/pc0/1420k/HICYL=159

The 1420k tells the device-handler to read 1420 KByte. The 1420 KByte are the value for the example (we have 2840 512 byte blocks, ie. 1420 KByte).

Take a look at the device-handler guide for a detailed description of its arguments.

Wether this problem arises with dd disk too is unknown.

Testsystem: Sun Solaris, GNU tar 1.11.8 Amiga 4000, C= hd disk drive, Geek Gadgets GNU tar 1.11.8

6.2.8 X Windows

Geek Gadgets features a X Windows port called 'Xgeek'. Although already very stable it is still undergoing constant development, especially lacking documentation thereof.

Please refer to the ASCII documentation included with the X11 packages for now.

6.3 Advanced topics

This section summarizes informations concerning advanced topics. You should be aware that these may require a more indepth knowledge of programming in general, programming for AmigaOS or using the Geek Gadgets Developers Environment.

6.3.1 Linker Libraries

Geek Gadgets provides replacements of the AmigaOS linker libraries.

6.3.1.1 libamiga.a

Starting from 2.6.0 an AmigaOS compliant linker (libamiga.a) is provided, thanks to libnix authors (Matthias Fleischer and Gunther Nikl).

Anyway if you want to rebuild one, there are two methods:

1) Using hunk2gcc; the AmigaOS object converter made by Markus Wild. To achieve this, simply grab a copy of latest amiga.lib (from Commodore Development Kit) and make a new directory where you want your converted object files to go, cd into it, and enter

hunk2gcc amiga.lib [..further libs if you like..]

This generates an a.out object file for every program unit present in the hunk file (in this case, from amiga.lib).

As the final step convert all those files into an a.out style library by issuing:

ar qc libamiga.a obj.* ranlib libamiga.a

The ranlib run builds a symbol table in the archive, and makes accesses to the library much faster.

2) Creating a libamiga.a library with libnix is fairly easy, but takes some time. Just decompress sources.lha from libnix distribution and run a 'make libamiga.a'.

NOTE:

As long as you make no AmigaOS specific calls, you can create a dummy library using:

cat "int dummy;" >dummy.c gcc -c dummy.c ar crv libamiga.a dummy.o mv libamiga.a gcc:lib

A small libamiga.a (dummy) is also provided with libnix.

Please be aware that the distributed libamiga.a exports several of its symbols, which means that you may end up with symbol name clashes or unexpected/undesired effects. For example, libamiga exports the array "color" in the Amiga custom chip address space, which clashes with a variable name color when compiling GNU chess.

6.3.1.2 libdebug.a

Since 2.7.2 an AmigaOS compatible libdebug.a is provided, thanks to Walter Harms.

6.3.2 How To Build an Amiga Cross Development Environment

6.3.2.1 Step 1: Pick an installation tree root directory

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.

6.3.2.2 Step 2: Pick a source tree root directory

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

6.3.2.3 Step 3: Pick a build tree root directory

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.

6.3.2.4 Step 4: Get and unpack the ixemul includes and libraries

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.

6.3.2.5 Step 5: Build/install binutils

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

6.3.2.6 Step 6: Build/install gcc

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

6.3.2.7 Step 7: Test the new cross toolchain

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

6.3.3 Debugging

[Details under construction]

6.3.3.1 gdb

[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.

6.3.3.2 trace

[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.

6.3.4 Networking code

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 6.2.3 ixemul.

6.3.5 Object format

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 6.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.


Go to the first, previous, next, last section, table of contents.