This chapter describes the usage of various parts of Geek Gadgets.
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.
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
:
man
since `manutils-2.x'. man
can call
groff
, see below
configure
scripts crash the machine
Please send suggestions about stack sizes to Fred Fish fnf@ninemoons.com
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).
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:
#include <stdlib.h> #include <stdio.h> #include <intuition/intuition.h> #include <proto/intuition.h> struct IntuitionBase *IntuitionBase = NULL; /* Explicit initialization with NULL is a *must*! */ void Cleanup(void) { if (IntuitionBase) CloseLibrary(IntuitionBase); } int main(int argc, char *argv[]) { if (atexit(Cleanup)) { perror("atexit"); exit(20); } if (!(IntuitionBase = (struct IntuitionBase *) OpenLibrary("intuition.library", 37))) { fprintf(stderr, "Cannot open intuition.library, V37"); exit(20); } /* Same program as above */ }Note the use of
atexit()
, which makes exit()
calling
Cleanup()
.
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.
Some Geek Gadgets tools (i.e. gcc
) are often (but not always)
memory hungry, a few tricks to save memory can make life easier:
cpp
, cc1
, as
and ld
directly instead of through the gcc
driver. This saves at least
one times your current stack size. Use the `-v' option to
gcc
to see what the command lines would look like and copy&paste
them.
avail FLUSH
in the Shell, reduce screen resolution
and depth, disable all floppy drives with the boot menu, disable the
S:Startup-Sequence and make a minimal one to execute instead.
A Geek Gadgets installation may well need lots of space on your storage media, a few tricks to save storage can make life easier:
amiga
, vt100
and xterm
entries from `etc/termcap'.
Lha
cannot handle hard links, thus current Geek Gadgets archives
contain duplicates where hard links should be used (e.g. `bin/ar' and
`m68k-amigaos/ar' and others are the same files). Another packaging
scheme will be used in the future to overcome this problem. See section 8. Future.
It is possible to link object files that were created by different conpilers, specifically GNU/C and SAS/C, as follows:
hunk2aout
tool to convert the object files from
amiga object format to aout object format.
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.
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:
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.
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. $
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.
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.
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".
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.
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
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.
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.
Geek Gadgets provides replacements of the AmigaOS linker libraries.
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.
Since 2.7.2 an AmigaOS compatible libdebug.a is provided, thanks to Walter Harms.
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
[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 6.2.3 ixemul.
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.