This is Info file gcc-faq.info, produced by Makeinfo-1.55 from the input file Amiga-GCC-FAQ.texi.  File: gcc-faq.info, Node: What GCC has to offer, Next: Hardware and Software Requirements, Prev: GNU and the GPL, Up: General Introduction What GCC has to offer. ====================== * A FREE C compiler, for starters. * It's available for a wide range of machines (and thus it can't be beat for cross-compiling, at least on the Amiga). * It's still actively supported. * For the interested, a chance to change it as you like, make your own bug fixes, be an active part in the development process.  File: gcc-faq.info, Node: Hardware and Software Requirements, Prev: What GCC has to offer, Up: General Introduction Hardware and Software Requirements ================================== This depends upon what you're doing, but here are some general guidelines. Systems Any Amiga (ranging from A1000 up to A4000/40, including CD-32 & SX-1) will run amigados-gnu utilities. Memory A minimum of 4MB free memory is needed in order to compile small/medium projects. More memory will be needed for large projects, such as recompiling gcc itself. Gigamem is known to work with GCC so *maybe* less memory will work. But in this case, you'll need an MMU equiped amiga (A3000,A4000/40, etc...). VMM40 (Public Domain Virtual memory manager) is also known to work with GCC. [Editor's note: using the g++ compiler can require even more, like at least 6 MB of free RAM] OS Version Starting from 2.6.3, 1.3 systems are not longer supported. Gcc runs fine on all other systems, starting from 2.04 up to 3.1 (40.68). Disk Space An installation of gcc requires the use of a hard disk. Approximately 10MB is required at present to install the compiler and utilities required to use it. In addition 3MB is required for the Commodore Developer Kit, which is required to be able to compile AmigaDOS specific programs. This kit is available direct from Commodore-Amiga. CD-ROM distributions sre generally configured to allow everything to be run off the CD-ROM, with a LOCAL: assign to point to modifications, third party development files, etc. Yes, it can take a lot of resources, but that's a function of its portability. Be glad you can count on having the same compiler on your Amiga at home or the Unix system at work (or vice versa :-)).  File: gcc-faq.info, Node: Obtaining and Installing the Beast, Next: Initial Problems with GCC, Prev: General Introduction, Up: Top Obtaining and Installing the Beast ********************************** * Menu: * Sources of the Amiga port of GCC:: * The Breakdown of the Distribution:: * Installation:: * Common Installation Problems::  File: gcc-faq.info, Node: Sources of the Amiga port of GCC, Next: The Breakdown of the Distribution, Up: Obtaining and Installing the Beast Sources of the Amiga port of GCC ================================ There are a couple of options for getting GCC. Net Distribution ---------------- If you have access to the Internet, and ftp service, you can obtain the current version of GCC from Aminet, in dev/gcc. The main site of Aminet is in /pub/aminet, and has mirrors world-wide: USA (MO) ftp.wustl.edu USA (WI) ftp.netnet.net USA (TX) ftp.etsu.edu Scandinavia ftp.luth.se Switzerland ftp.eunet.ch Switzerland ftp.math.ethz.ch Germany kelly.uni-paderborn.de Germany ftp.uni-paderborn.de Germany ftp.uni-stuttgart.de Germany ftp.uni-erlangen.de Germany ftp.cs.tu-berlin.de Germany ftp.tu-chemnitz.de Germany ftp.fh-augsburg.de Germany ftp.uni-bremen.de Germany ftp.uni-kl.de Germany ftp.uni-trier.de Germany ftp.informatik.rwth-aach France ftp.cnam.fr Portugal ftp.ci.ua.pt UK ftp.doc.ic.ac.uk UK micros.hensa.ac.uk `' also serves to act as a hub for porting GNU software to the Amiga, and serves to mirror Phillipe Brand's Amiga GCC tree directly, so that you may always find GCC there (particularly to guarantee the availability of source code). ADE distribution ---------------- `' also carries a distribution of gcc binaries and source. They will generally be more up to date than the latest Aminet distribution. Make sure you check in the Breakdown of the Distribution for which files you should get. The ADE ftp tree can be found at the following locations: Site Name IP Address Directory Comments --------- ---------- --------- -------- ftp.ninemoons.com 165.247.33.6 pub/ade (master site) ftp.grolier.fr 194.158.97.67 pub/amiga/ade (full mirror) bilbo.di.unipi.it 131.114.4.62 pub/ade (latest + updates) CD-ROM distributions -------------------- CD-ROM distributions are particularly handy ways of obtaining GCC (and other free tools). Unfortunately, the FreshFish CD-ROM is no longer in production due to lack of market. However, Cronus will make a custom CD with the current ADE development tree in a ready to run form for $50. See for more details. The Amiga Developer's CD may also be a source of the ADE development tree (I'm not sure).  File: gcc-faq.info, Node: The Breakdown of the Distribution, Next: Installation, Prev: Sources of the Amiga port of GCC, Up: Obtaining and Installing the Beast The Breakdown of the Distribution ================================= Net Distribution ---------------- The net distribution of gcc is broken up into several parts, both to make it easier to download and to respect the GPL. Thus each archive is broken into two parts, one for binaries and one for sources. Gcc-2.7.0 is split up into 15 archives: `gcc270-base.lha' 1568247 950902 Gcc v2.7.0 - Base part - C/C++/ObjC Compiler set for AmigaDOS `gcc270-c.lha' 777638 950902 Gcc v2.7.0 - C part - C/C++/ObjC Compiler set for AmigaDOS `gcc270-c020.lha' 724964 950902 Gcc v2.7.0 - 68020 C part - C/C++/ObjC Compiler set for AmigaDOS `gcc270-cp.lha' 1837009 950902 Gcc v2.7.0 - C++ part - C/C++/ObjC Compiler set for AmigaDOS `gcc270-cp020.lha' 1804177 950902 Gcc v2.7.0 - 68020 C++ part - C/C++/ObjC Compiler set for AmigaDOS `gcc270-doc.lha' 1191858 950902 Gcc v2.7.0 - Doc part - C/C++/ObjC Compiler set for AmigaDOS `gcc270-inclib.lha' 939537 950902 Gcc v2.7.0 - Headers and Libs part - C/C++/ObjC Compiler set for AmigaDOS `gcc270-objc.lha' 654300 950902 Gcc v2.7.0 - Objc part - C/C++/ObjC Compiler set for AmigaDOS `gcc270-objc020.lha' 631745 950902 Gcc v2.7.0 - 68020 Objc part - C/C++/ObjC Compiler set for AmigaDOS `gcc270-readme.lha' 121957 950902 Gcc v2.7.0 - README part - C/C++/ObjC Compiler set for AmigaDOS `gcc270-src.lha' 8212723 950902 Gcc v2.7.0 - Sources part - C/C++/ObjC Compiler set for AmigaDOS `gccdoc.lha' 1674382 930318 GNU CC documentation in TeX and Postscript format `ixemul-000s.lha' 86332 960530 IXemul 43.1 - 68000 library `ixemul-000t.lha' 88218 960530 IXemul 43.1 - 68000 trace library `ixemul-020f.lha' 83997 960530 IXemul 43.1 - 68020+fpu library `ixemul-020s.lha' 84269 960530 IXemul 43.1 - 68020 library `ixemul-030f.lha' 93465 960408 IXemul 43.0 - 68030+fpu library `ixemul-030s.lha' 93755 960408 IXemul 43.0 - 68030 library `ixemul-040f.lha' 84141 960530 IXemul 43.1 - 68040+fpu library `ixemul-040s.lha' 84269 960530 IXemul 43.1 - 68040 library `ixemul-bin.lha' 35059 960530 IXemul 43.1 - various utilities `ixemul-doc.lha' 42880 960530 IXemul 43.1 - various documentation `ixemul-sdk.lha' 1618566 960530 IXemul 43.1 - developer's tool kit `ixemul-src.lha' 1887510 960530 IXemul 43.1 - full source code `ixemul-tz.lha' 214230 960530 IXemul 43.1 - TZ management files `ixpath.lha' 12544 951223 Patch dos to use ixemul style path parsing `ixprefs1.2.lha' 52561 950704 Ixemul 41.0-41.1 GUI/CLI config program `libnixV1_1.lha' 374467 960310 A static library for gcc (V1.1) ADE distribution ---------------- The ADE distribution is quite a bit different from the net distribution. From the README: The ADE is can be divided into several distinct files trees, as follows: ADE-bin Binary tree where executables, runtime libraries, user documentation, etc live in "ready-to-run" form. Uses "ADE:" as an alias (Amiga assign). The files in this area are built from source in ADE-src or copied from files in ADE-src. ADE-src Source tree which contains all the sources for components of the ADE. Given the ADE-src tree, and a copy of the ADE-bin tree, it should be possible to completely recreate the ADE-bin and ADE-dist trees. ADE-dist Tree which contains material from ADE-bin and ADE-src, archived in a form suitable for BBS or ftp access. Also contains baseline source archives for packages which have been modified and diff files for the Amiga sources relative to this baseline. The ADE-dist tree normally contains several files for each program. As an example, here are the names of the files for the GNU C compiler. Each file also has an associated product info file which has the same name but an additional suffix of ".pi": gcc-X.X.X-base.tgz Baseline source before incorporation into the ADE. In some cases base files have been reorganized to match the same file tree structure as used for the Amiga source in the ADE, so that diff files can be mechanically generated. gcc-X.X.X-bin.lha The binary package for GNU C, C++, and Objective C. gcc-X.X.X-src.tgz The Amiga source from which the supplied binaries were compiled. gcc-X.X.X-diffs.gz The diffs from the baseline to the Amiga source. The baseline source, amiga source, and diff file form a complete source distribution. In theory, only any two of these are needed, since the third can be regenerated from either of the other two. Note that `.tgz' is short for `.tar.gz', which is a gzip compressed tar archive. To extract the contents, you would do something like: tar -xvpzf gcc-X.X.X-base.tgz If this causes you any problems, you can use pipes to do the decompression and tar extraction as two separate processes, without creating a temporary file: zcat gcc-X.X.X-base.tgz | tar -xvpf - Without using pipes, you can create a temporary file to extract from, as follows: zcat gcc-X.X.X-base.tgz >gcc-X.X.X-base.tar tar -xvpf gcc-X.X.X.tar The minimum set of packages is: - ADE-misc-bin.lha - binutils-X.X-bin.lha - bison-X.X-bin.lha - diffutils-X.X-bin.lha - fifo-X.X-bin.lha - fileutils-X.X-bin.lha - findutils-X.X-bin.lha - flex-X.X-bin.lha - gcc-X.X-bin.lha - grep-X.X-bin.lha - gzip-X.X-bin.lha - ixemul-X.X-bin.lha - ixemul-X.X-env-bin.lha - ixemul-X.X-inc-bin.lha - ixpipe-X.X-bin.lha - libamiga-bin.lha - libg++-X.X-bin.lha - libm-X.X-bin.lha - libnix-X.X-bin.lha - make-X.X-bin.lha - os-inc-bin.lha - patch-X.X-bin.lha - pdksh-X.X-bin.lha - sed-X.X-bin.lha - sh-utils-X.X-bin.lha - tar-X.X-bin.lha - termcap-X.X-bin.lha - textutils-X.X-bin.lha  File: gcc-faq.info, Node: Installation, Next: Common Installation Problems, Prev: The Breakdown of the Distribution, Up: Obtaining and Installing the Beast Installation ============ Net Distribution ---------------- Installation procedures may vary depending on your source, but the final directory structure should be the same. Check the `README' files included in your distribution package for more details. The ftp distribution (Phillipe Brand's) contains an Installer program. It utilizes the following layout: Name What Where COPYING GNU LICENSE, read!! All archives COPYING.LIB GNU LIBRARY LICENSE, read!! All archives README-2.6.3 this file All archives NEWS-2.6.3 What's new in gcc-2.6.3 gcc263-base Installer Commodore installer utility gcc263-base GCC-Install Installer script to configure gcc All archives envarc/ global environment variables you should have set when using this programming gcc263-base environment include/ non-amiga specific C/C++ headers gcc263-inclib os-include/proto amiga specific protos headers. gcc263-inclib os-include/inline amiga specific inline C headers. Add gcc263-inclib Commodore headers!! os-lib/ amiga specific libraries gcc263-base guide/ Docs in AmigaGuide(tm) format gcc263-doc man/ this is the root for tons of man pages gcc263-doc bin/ this is /bin, and contains all gcc263-c binaries of this distribution that gcc263-c++ are meant to be directly invoked by gcc263-utils the user (contrary to the executables in lib/gcc-lib/, that are meant to be invoked by a driver program like gcc) lib/ normal (not base relatives) libraries gcc263-inclib lib/libm020/ normal 68020 libraries gcc263-inclib lib/libb/ base relatives libraries gcc263-inclib lib/libb/libm020/ base relatives using 68020 libraries gcc263-inclib lib/libnix/ Non-ixemul libraries gcc263-inclib lib/libm020/libnix/ Non-ixemul 68020 libraries gcc263-inclib lib/libb/libnix/ Non-ixemul base relatives libraries gcc263-inclib lib/libb/libm020/libnix Non-ixemul base relatives 68020 libs gcc263-inclib lib/gcc-lib/ home of compilers called by gcc gcc263-c gcc263-c++ gcc263-objc ixpipe/ a pipe handler needed by the library gcc263-base libs/ ixemul.library gcc263-base rexx/ ARexx wrappers for gcc and g++ gcc263-base src-patches/ source patches gcc263-diffs geninline/ Perl scripts to generate inline headers gcc263-inclib and -lamy glue A standard GNU directory tree structure has been adopted by the porting team to make life easier for everyone. Starting with the assign of GNU: to somewhere, we then have: GNU:amigados GNU:man GNU:Info GNU:etc GNU:bin GNU:include GNU:lib GNU:os-include GNU:os-lib Since one of the aims of porting GNU software is to be able to provide a Un*x like environment under AmigaOS, the porters decided to make a GNU "root directory" (`GNU:') in which a standard Un*x directory tree can live, like `/etc', `/bin', and so on. This decision makes for good Un*x compatibility. Also, in the past, you would have to add many assigns (>=10) to have your GNU utilities working, and now it's just 5 (`GNU:', `MAN:', `INFO:',`ETC:', and `BIN:'). We no longer have a conflicting assign `LIB:' (which most other compilers use). The above information is out of date (though true for older distributions). Currently the GNU directory has been changed to the ADE directory, and even fewer assigns are needed. Furthermore, all current programs from the ADE distribution refer to the ade directory and not the gnu assign. ADE distribution ---------------- Currently the only supported method of installing components of the ADE is to create a directory which will be the root of the ADE binary tree, assign ADE: to this directory, cd to ADE:, and use lha to extract the contents of the packages you wish to install (everything is archived relative to ADE:). For example, the following illustrates populating the ADE binary tree with the minimum set of packages that we would recommend for doing serious C or C++ development. Replace `-X.X-' with the appropriate version numbers for the current release: makedir dh0:ADE assign ADE: dh0:ADE cd ADE: lha -mraxe x ADE-misc-bin.lha lha -mraxe x binutils-X.X-bin.lha lha -mraxe x bison-X.X-bin.lha lha -mraxe x diffutils-X.X-bin.lha lha -mraxe x fifo-X.X-bin.lha lha -mraxe x fileutils-X.X-bin.lha lha -mraxe x findutils-X.X-bin.lha lha -mraxe x flex-X.X-bin.lha lha -mraxe x gcc-X.X-bin.lha lha -mraxe x grep-X.X-bin.lha lha -mraxe x gzip-X.X-bin.lha lha -mraxe x ixemul-X.X-bin.lha lha -mraxe x ixemul-X.X-env-bin.lha lha -mraxe x ixemul-X.X-inc-bin.lha lha -mraxe x ixpipe-X.X-bin.lha lha -mraxe x libamiga-bin.lha lha -mraxe x libg++-X.X-bin.lha lha -mraxe x libm-X.X-bin.lha lha -mraxe x libnix-X.X-bin.lha lha -mraxe x make-X.X-bin.lha lha -mraxe x os-inc-bin.lha lha -mraxe x patch-X.X-bin.lha lha -mraxe x pdksh-X.X-bin.lha lha -mraxe x sed-X.X-bin.lha lha -mraxe x sh-utils-X.X-bin.lha lha -mraxe x tar-X.X-bin.lha lha -mraxe x termcap-X.X-bin.lha lha -mraxe x textutils-X.X-bin.lha The following should be optional, unless you want to remake a "configure" file, want EMACS, or current need a libcurses library (should be replaced soon with ncurses): lha -mraxe x autoconf-X.X-bin.lha lha -mraxe x emacs-X.X-bin.lha lha -mraxe x libcurses-X.X-bin.lha You may want to examine the ixemul.library flavors in `ADE:Sys/Libs' and select one more appropriate for your specific machine. For example, A4000 users might want to remove the default ixemul.library (68000) and copy `ixemul040fpu.library' to `ixemul.library'. If you want to just do libnix development and not ixemul development, note that you still need the include files from `ixemul-X.X-inc-bin.lha'. You should also ensure that you have an environment variable called `HOME', which should point to a local directory that can be used to contain "reconfiguration scripts" that many tools look for. As an example, the following is a useful definition for `$HOME/.inputrc': # My ~/.inputrc file is in -*- text -*- for easy editing with Emacs. # # Notice the various bindings which are conditionalized depending # on which program is running, or what terminal is active. # # In all programs, all terminals, make sure this is bound. "\C-x\C-r": re-read-init-file # Amiga console specials "": delete-char "›A": previous-history "›B": next-history "›C": forward-char "›D": backward-char Once you are done, arrange to assign `ADE:' in your startup, arrange to execute `ADE:Sys/S/ADE-Startup' at boot time, and reboot. Once you've started using ADE, the `ADE-Startup' adds all necessary assigns to subdirectories of `ADE:'. So you do not need to, for example, copy `ixemul.library' to `LIBS:'. In fact, if have been using the net distribution, you should make sure that all their binaries are cleaned out of `C:', `LIBS:', `L:', etc. as they will interfere with the more current ade distribution. For example, make sure you delete `ixemul.library' from `LIBS:'.  File: gcc-faq.info, Node: Common Installation Problems, Prev: Installation, Up: Obtaining and Installing the Beast Common Installation Problems ============================ Using the Installer program for the net distribution should get rid of any problems. Check out the GNU documentation on the `specs' file if you are having problems customizing your installation (say you have another compiler, and don't want to have 2 separate copies of `os-include'). Also, for those of you who refuse to read the `README', you need the Commodore includes. *Note Getting the Commodore includes::. You may need to convert some standard libraries. *Note The object file format of GCC::. Another common problem is crashes due to having too little stack. *Note Set your stack properly::. Most of these problems have been overcome and should not be problems for current net distributions.  File: gcc-faq.info, Node: Initial Problems with GCC, Next: Amiga-specific extensions, Prev: Obtaining and Installing the Beast, Up: Top Initial Problems with GCC ************************* * Menu: * Set your stack properly:: * Amiga specific Library options:: * The object file format of GCC:: * Getting the Commodore includes:: * The frontend of the compiler:: * Optimization may work where no optimization doesn:: * Using the OS functions with gcc:: * Removing Debug Symbols::  File: gcc-faq.info, Node: Set your stack properly, Next: Amiga specific Library options, Up: Initial Problems with GCC Set your stack properly ======================= [Note: this warning is dated as versions >= 2.7.0 include automatic stack checking.] GCC needs a lot of stack to run. For a nice, small (<1000 lines) source, a stack of 50,000 should do just fine. For more complicated code, you may need more, but 250,000 should do in any case, for gcc alone. Note that using make may increase the demands on the stack size, so the above suggestions may not hold. A word from Phillipe Brand's README: You need to have a 50,000 stack size in order to compile with GCC. This should be enough for most projects. Note than while recompiling gcc with itself it has taken more than 300KB stack. Stack can grow due to source complexity. Don't be afraid of it. To set the stack size, see the AmigaDOS Command `stack'. To use `ar' and/or `ranlib', 50KB is the minimum acceptable. You should have a much larger stack, if you use larger libraries. Starting with 2.6.3 a new environnement variable, `GCCSTACK', enables gcc to read this variable and set stack upon startup. Thus now no need to set stack to huge values, only `gcc/ld/cpp/cc1#?' will automatically set new stack, according to `GCCSTACK' variable. Simply commit a: setenv GCCSTACK value to set gcc stack to value. Benefits: huge memory savings. Note that GCC 2.7.2 includes automatic stack growth code, so you won't need to worry about this anymore. Actually 2.7.0 didn't quite solve this problem, but (I believe) that it has been solved in the latest ADE distribution. However, the `GCCSTACK' environment variable conflicts with the automatic stack extension code, and has therefore been removed.  File: gcc-faq.info, Node: Amiga specific Library options, Next: The object file format of GCC, Prev: Set your stack properly, Up: Initial Problems with GCC Amiga specific Library options ============================== * Menu: * Ixemul.Library:: * libnix:: * Gerlib:: * the PDC library::  File: gcc-faq.info, Node: Ixemul.Library, Next: libnix, Up: Amiga specific Library options Ixemul.Library -------------- 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, GCC has programs it compiles 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. The general rule of thumb should be to use ixemul.library if you're writing something non-Amiga specific (e.g. porting something) or one of the below link libraries when writing something specifically for the Amiga. You can use the ixprefs program to set various options of ixemul.library.  File: gcc-faq.info, Node: libnix, Next: Gerlib, Prev: Ixemul.Library, Up: Amiga specific Library options 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: * It's mostly compatible to SAS's way of handling things, i.e. you get even an automatic shared library opening feature and some other things you may miss in ixemul.library. This also means it's ANSI compliant. * It doesn't need any shared libraries than normal Amiga OS ones. * It is not copyrighted by the FSF. Therefore you neither need to include sources nor objects together with your executable. (read the GLGPL _before_ flaming on this statement) * And it's short! I was able to compile a 492 byte 'hello, world' using normal main. * It uses OS20 features whenever necessary. 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. But if you use an older gcc version or if you want to get the sources you can take this package. But be warned: The ld that comes with earlier versions of gcc has some serious trouble with set elements. You cannot use libnix without the fixed linker that comes with gcc2.6.0.  File: gcc-faq.info, Node: Gerlib, Next: the PDC library, Prev: libnix, Up: Amiga specific Library options Gerlib ------ Obsolete. Well, unless you want to develop for 1.3 systems.  File: gcc-faq.info, Node: the PDC library, Prev: Gerlib, Up: Amiga specific Library options the PDC library --------------- Obsolete. Well, unless you want to develop for 1.3 systems.  File: gcc-faq.info, Node: The object file format of GCC, Next: Getting the Commodore includes, Prev: Amiga specific Library options, Up: Initial Problems with GCC The object file format of GCC ============================= Yes, GCC uses its own object file format. This means you aren't currently able to link to AmigaDOS hunk format object files (standard). But hunk2gcc (by Markus Wild) will do the conversion for you as described below. 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 AmigaDOS hunks. [From Brand's README-2.6.3] Starting from this release an AmigaDOS compliant library 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 AmigaDOS 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 uncompress sources.lha from libnix distribution and run a 'make libamiga.a'. NOTE: As long as you make no AmigaDOs 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. [current] Now libamiga.a has its own archive in the ADE tree, and is not the Commodore copyrighted one. If for some reason you need the original, you will have to follow the above procedures to get it.  File: gcc-faq.info, Node: Getting the Commodore includes, Next: The frontend of the compiler, Prev: The object file format of GCC, Up: Initial Problems with GCC Getting the Commodore includes ============================== [Jochen Wiedmann] You can obtain the includes and some developer tools from any Fish CD and some other CD's as well. However, you will be missing the autodocs, which are definitely the best information source for the OS functions. You can get them either by buying the The Amiga ROM Kernel Manual: Includes and Autodocs, ISBN 0-201-56773-3 (about 50-60$, as far as I know), or by buying the so-called NDU (Native developers update kit, 5 disks, about 40$) from Fa. Hirsch & Wolf Mittelstr. 33 56564 Neuwied Germany Phone: (0049) +2631 83990 Email: hhhirsch@carla.adsp.sub.org Sorry, but this is still the *only* source for the NDU, at least as long as CATS (Commodore Amiga Technical Support) isn't alive. I'd prefer buying the NDU, because it contains the newer information than the book and I prefer it online. [Rask Lambertsen] [The C= includes are available via FTP from in directory cdrom/bbs/cbm. URL: file://ftp.dfv.rwth-aachen.de/cdrom/bbs/cbm/ The latest package is nduk-v40.lha. It includes includes (asm and C), fd-files and a few developer tools (Atom, Alink, ...). Just to advertice a little for my homepage (sorry), I keep an up-to-date link to the OS includes. They seem to move around from time to time.  File: gcc-faq.info, Node: The frontend of the compiler, Next: Optimization may work where no optimization doesn, Prev: Getting the Commodore includes, Up: Initial Problems with GCC The frontend of the compiler ============================ `amigados-gcc' and `gcc' are the same thing. Since `fork()' is unimplemented in ixemul.library, `gcc' has been replaced by `gccv' (uses `vfork()' instead of `fork()'). AREXX scripts [Phillipe Brand's README]: The provided ARexx scripts have been contributed by Loren J. Rittle. If you like ARexx, they're an alternate way of calling gcc. They automatically make sure you're using a large enough stack setting, and enable you to compile C++ programs with less obscure options. This approach is furthermore useful if you're not able to use the g++ /bin/sh script. These scripts should no longer be necessary.  File: gcc-faq.info, Node: Optimization may work where no optimization doesn, Next: Using the OS functions with gcc, Prev: The frontend of the compiler, Up: Initial Problems with GCC Optimization may work where no optimization doesn't =================================================== The folks who write GCC almost always use `-O' when compiling GCC and other stuff. Hence, the `-O' routines are better tested than those without optimization. So you may want to try it.  File: gcc-faq.info, Node: Using the OS functions with gcc, Next: Removing Debug Symbols, Prev: Optimization may work where no optimization doesn, Up: Initial Problems with GCC Using the OS functions with gcc =============================== [Jochen Wiedmann, with a small suggestion by Christian Stieber] Let's write a simple "HelloWorld.c": /* Compile me with gcc -noixemul -o HelloWorld HelloWorld.c -lauto */ #include #include #include int main(int argc, char *argv[]) { struct EasyRequest er; er.es_StructSize = sizeof(er); er.es_Flags = 0; er.es_Title = "Message"; er.es_TextFormat = "Hello, world!\nintuition.library is at 0x8l."; er.es_GadgetFormat = "Ok"; EasyRequest(NULL, &er, NULL, IntuitionBase); exit(0); } Some notes: * We are using the function EasyRequestArgs() from intuition.library. Thus we have to include the appropriate headers: intuition/intuition.h for the structures and constants, proto/intuition.h for the function prototypes. Do not use headers from other compilers (for example pragmas/intuition.h), gcc headers (inline/intuition.h, included by proto/intuition.h) or even OS headers (clib/intuition_protos.h). The only exception are clib/alib_protos.h and clib/alib_stdio_protos.h: These represent link libraries and not shared libraries. * We did *not* open intuition.library. gcc does this for you by including proto/intuition.h and linking against libauto.a. However, this works only for OS libraries. Consult the GNU:libauto directory, if you want to know how to get the same possibilities for other shared libraries. Using proto/intuition.h you are safe and even source compatible to SAS/C and Dice. * If you *need* to open a library manually, do it as follows: #include #include #include #include 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()'. Note this possible alteration: struct EasyRequest er; er.es_StructSize = sizeof(er); This seems to be correct, but I suggest hardcoding 5*sizeof(ULONG) here. That field serves as version information; using sizeof() and compiling with newer headers would tell the OS that you're using the new structure. But the additional fields will contain garbage...  File: gcc-faq.info, Node: Removing Debug Symbols, Prev: Using the OS functions with gcc, Up: Initial Problems with GCC Removing Debug Symbols ====================== By default, GCC will leave the debugging symbols in the executable. To turn this off, simply use `-s' on the command line when you compile. It could significantly reduce the size of your executable. `ssystem()' not implemented error ================================= As of `ixemul' version 43.1, `fork()' is no longer supported at all, and hence `ssystem()' isn't supported either. The `gcc' executable in the 2.7.0 distribution still uses `ssystem()', so you need to remove that executable, and rename `gccv' (which uses `system()') to `gcc'. These executables should be found in a subdirectory of `ADE:lib/gcc-lib/' (depends on which distribution you have).  File: gcc-faq.info, Node: Amiga-specific extensions, Next: Advanced Questions, Prev: Initial Problems with GCC, Up: Top Amiga-specific extensions ************************* * Menu: * The CHIP keyword:: * Command Line options::  File: gcc-faq.info, Node: The CHIP keyword, Next: Command Line options, Up: Amiga-specific extensions The CHIP keyword ================ Most C compilers for the Amiga have a CHIP keyword or equivalent to signify that an object should stored CHIP memory when declared. I.e., CHIP struct Image *my_graphics = { ... } will cause the memory for the data to which my_graphics points to be allocated in CHIP memory (pretty handy, huh?) This is obviously Amiga-specific, so of course it's not implemented in the FSF code. BUT, the linker (ld) currently recognizes -chip and -fast options. However, these aren't in gcc itself, mainly because gcc doesn't output files in the right format to load data directly to chip memory. However, there are several workarounds. The first is software based, mainly you declare and define your data as an array (or whatever), then Allocmem(sizeof(data),MEMF_CHIP), then copy the data from your original data structure using cpymem(). [Lars Hecking] I have written this code years ago to use Intuition++ (still on Aminet) with g++. The BOOL return type could be replaced with int, returning appropriate values instead of TRUE and FALSE. Everything should be self-explanatory ;-) begin>> chip USHORT CTRL_ImageData[] = { .... }; becomes extern USHORT CTRL_ImageData[]; USHORT *CTRLImageData; BOOL AllocInitChipData() { CTRLImageData = (USHORT *)AllocMem (sizeof(CRTL_ImageData),MEMF_CHIP); if (CTRLImageData == (USHORT *)NULL) return FALSE; CopyMemQuick ((APTR)&CTRL_ImageData[0], (APTR)CTRLImageData, sizeof(CRTL_ImageData)); return TRUE; } void FreeChipData() { FreeMem ((APTR)CTRLImageData,sizeof(CTRL_ImageData)); } end>> The second way is to use a program like Bin2Hunk (on Aminet in `/dev/misc/BintoHunk.lha'), which will take a data file and make it into a linkable object file. The documentation for Bin2Hunk tells you how to specify variable names for the data in this file so you can reference this data from within your program. This seems like a better solution than the first since you don't have to deal with dynamically allocating memory and copying it. However, I haven't tested this program myself or this way of doing things - please let me know if it works and how well. The third way would be to use another compiler that allows the `CHIP' keyword to compile the source code containing the data that you want in `CHIP' memory, then link to it. This doesn't have to mean SAS/C. If you're just using it to compile a file that's just a bunch of CHIP UBYTE *data { whatever ...} you could probably use any Amiga native compiler, even if it's old and decrepit for doing anything else. Let me know if you find a good, cheap or free compiler for this (maybe the old PDC, or the DICE demo version will do it). Certainly an old copy of Lattice 5.10 should be able to handle this.  File: gcc-faq.info, Node: Command Line options, Prev: The CHIP keyword, Up: Amiga-specific extensions Command Line options ==================== * Menu: * -noixemul:: * -fbaserel (not available in pre-2.7.0):: * -resident::  File: gcc-faq.info, Node: -noixemul, Next: -fbaserel (not available in pre-2.7.0), Up: Command Line options `-noixemul' ----------- This option prevents gcc from making your executable open ixemul.library (of course, your program can still do so). Make sure you link to libnix or something similar to access those functions.  File: gcc-faq.info, Node: -fbaserel (not available in pre-2.7.0), Next: -resident, Prev: -noixemul, Up: Command Line options `-fbaserel' (not available in pre-2.7.0) ---------------------------------------- [Christian Stieber] `-fbaserel' turns on base relative addressing; which means that global/static variables are referenced with a 16 bit offset relative to an address register (a4 is generally used for that). The startup-code loads a4 with a pointer into the data segment. Result: every access to a global/shared variable is only 16 bit instead of the usual 32 bit address which is shorter and faster. It also means that you're limited to at most 64K of global/static variables. Make sure you link to baserel libraries when you use this option(!). The standard configuration of gcc should specify baserel versions of standard libraries be used, but make sure if you make your own that they are baserel too.  File: gcc-faq.info, Node: -resident, Prev: -fbaserel (not available in pre-2.7.0), Up: Command Line options `-resident' ----------- [Christian Stieber] A "resident" program (the correct term is "pure") is a program that can be loaded into memory just once, but executed by serveral processes at the same time. Therefore, "resident" is actually "code sharing". -resident turns on -fbaserel and links with a special startup code. That first thing that special startup code is to allocate some memory, copy the global/static variables into it and load a4 with a pointer to that memory. Then, a normal startup-code and your normal program is run. When the program exists, the memory block is freed. Result: Every process has its very own, private data segment for global/static variables. Since there all global/static variables are accessed via a4+16-bit-offset (because of `-fbaserel'), the original data segment is untouched. Result: the program can be executed independently by several processes, with every process getting its own data segment.  File: gcc-faq.info, Node: Advanced Questions, Next: C++ and Objective C, Prev: Amiga-specific extensions, Up: Top Advanced Questions ****************** * Menu: * How do I build a cross-compiler?:: * Working with AmiTCP:: * Writing code for ixemul.library:: * Writing code for libnix:: * Problems with asm():: * How do I save RAM?:: * Writing shared libraries and resident (pure) code:: * I want to change from SAS/C to GCC:: * Inline Headers:: * Writing Hooks::  File: gcc-faq.info, Node: How do I build a cross-compiler?, Next: Working with AmiTCP, Up: Advanced Questions How do I build a cross-compiler? ================================ [from Phillipe Brand] How to generate a cross-compiler, AmigaDOS side: - Get gcc-2.6.3.tar.gz from ftp.gnu.ai.mit.edu or mirror site - Get ftp.telesys-innov.fr:/pub/amigados-gnu/gcc-2.6.3-amiga.diffs file >From CLI: CLI> sh # zcat gcc-2.6.3.tar.gz | tar xvf - # cd gcc-2.6.3 # zcat ../gcc-2.6.3-amiga.diffs | patch -p1 # ./configure --host=amigados --target=CPU-COMPANY-SYSTEM # make When compilers are built, all you have to do is installing it using make install, and to grab other architecture's libraries (libc.a, etc...), and headers. More infos: See GCC AmigaGuide documentation, look for "Cross-Compiling". How to generate a cross-compiler, Other architecture side: - Get gcc-2.6.3.tar.gz from ftp.gnu.ai.mit.edu or mirror site - Get ftp.telesys-innov.fr:/pub/amigados-gnu/gcc-2.6.3-amiga.diffs file >From CLI: CLI> sh # zcat gcc-2.6.3.tar.gz | tar xvf - # cd gcc-2.6.3 # zcat ../gcc-2.6.3-amiga.diffs | patch -p1 # ./configure --target=amigados (host should be determined by configure itself) # make When compilers are built, all you have to do is installing it using make install, and to grab AmigaDOS GCC libraries (libc.a, etc...), and headers. More infos: See GCC AmigaGuide documentation, look for "Cross-Compiling". A working example of a cross-compiler running on sunos4.1.3 can be found in `ftp.telesys-innov.fr:/pub/amigados-gnu/gcc-cross/....'  File: gcc-faq.info, Node: Working with AmiTCP, Next: Writing code for ixemul.library, Prev: How do I build a cross-compiler?, Up: Advanced Questions Working with AmiTCP =================== Working with Amitcp and AS225 is now (as of ixemul.library version 43.0) transparent when you use ixemul.  File: gcc-faq.info, Node: Writing code for ixemul.library, Next: Writing code for libnix, Prev: Working with AmiTCP, Up: Advanced Questions Writing code for ixemul.library =============================== After looking at Markus Wild's README, I couldn't see anything to include in particular, and the thing is way too long to put here. Any specific suggestions of stuff to clip out? Actually, considering the update activity, the current maintainers/ developers should be providing a new README. Particularly the functions available in the different versions (regular fxns, the ones in the network version, and the conflicts. Somebody recently answered a question about this last part, saying he was trying to integrate the 2). * Menu: * Finding bugs with trace()::  File: gcc-faq.info, Node: Finding bugs with trace(), Up: Writing code for ixemul.library Finding bugs with trace() ------------------------- [Joerg-Cyril Hoehle] More than one year ago, I corrected a huge bug in the program trace (a buffer overflow). 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. Before, because of that overflow, trace hung the whole system very often (and very soon) when tracing every ixemul call. Now, I've been able to trace long sessions of gcc compilation to a (K)CON: window without trouble. *Note Debuggers::.  File: gcc-faq.info, Node: Writing code for libnix, Next: Problems with asm(), Prev: Writing code for ixemul.library, Up: Advanced Questions Writing code for libnix ======================= You should really grab the documentation for libnix from the libnix source archive and read it. But in the meanwhile, here's a warning from one of the authors of libnix: [Gunther Nikl] Let's write a simple "HelloWorld.c": /* Compile me with gcc -noixemul -o HelloWorld HelloWorld.c -lauto */ ^^^^^^ When using the `-noixemul' switch it is NOT nessecary (and better avoided) to use `-lauto'. libnix uses an own technique to open the system libraries. Using `-noixemul' and `-lauto' together means that all system libraries will be opened twice... The `libauto.a' is only useful for IXEMUL linked programs.