From: ridderbusch.pad@sni-usa.com (Frank Ridderbusch, STO SI211)
Newsgroups: comp.sys.atari.st
Subject: Re: GCC / G++ setup again (Is this the solution ???)
Date: 16 Oct 92 12:12:05 GMT
Organization: Siemens Nixdorf Informationssysteme AG, Paderborn, Germany
X-Md4-Signature: dc4fb6f59c1cf4422c8f2d3cdbd4c99b

In article <1992Oct13.232839.3277@mcshh.Hanse.DE> dk3uz@mcshh.Hanse.DE (Edmund Ramm) writes:

> saj@chinet.chi.il.us (Stephen Jacobs) writes:

> >It is not useful or appropriate to tell me to RTFM.  I have.  It's out of
> >date, and fragmented.  Or rather, with all the hands working on keeping
> >GNU stuff current on the ST, the world is fragmented.  I'm asking for a
> >central location to look to find out how things stand ->now<-.
>    I couldn't agree more violentissimo!!!

>    cu, Eddi


> UUCP:     uunet!mcsun!unido!mcshh.hanse.de!dk3uz     |  Real:  Edmund H. Ramm
> AMPRNET:  dk3uz%dk3uz@db0hhn.ampr.org [44.130.0.81]  |  AX.25: dk3uz@db0hb

Well, you talk about documentation. Here is an updated extract from
the installation section of the file gcc-st.txi, which should be
available from a.a.

Tell me, if you can get GCC run with this info or not. If you can not,
then tell me why (bad english, bad grammar). I'm gratefull for every
hint. 

============================================================
Installing GCC
***************

   There are basically three components, which make up a basic compiling
system and which have to be installed. Each component is accessed via an
environment variable. This three components are:

*The executables*
     These are accessed via the normal `PATH' variable, by which all
     other programs are found and the variable `GCCEXEC'.

*The header files*
     The preprocessor accesses the header files via the variable
     `GNUINC'. Any C++ header files are accessed via `GXXINC'

*The libraries*
     The linker finds the startup file and the required libraries via
     the variable `GNULIB'. The C++ library also belongs into this
     directory.

   All this stuff basically assumes that you're using a CLI (command
line interpreter). A really good choice is Gulam, which has very nice
set of features, but there are quite a number of other CLI's around,
which also might do the job. If want as much U**x feeling as possible,
you might consider either `ash', which is compatible to the Bourne shell
(ported by Stefan Neuhaus), or E.R.Smiths port of `tcsh' or Scott
Kolodzieskis port of BASH 1.12.

   Apart from the CLI you definitely should get yourself a make
utility. Again, good choices here are either the GNU Make, which offers
nearly the complete U**x make functionality on the ST or the PDMAKE,
which has only the core make functionality, but has on the other hand
the advantage, that it requieres fewer system resources.

   I suggest the following directory structure on your disk partition:

`\gnu\bin'
     for all executable programs. The compiler driver finds the
     executables in this directory by looking up the environment
     variable `GCCEXEC'.

`\gnu\lib'
     for the startup object modules and the libraries. The linker find
     the startup code and the libraries in this directory by looking up
     the variable `GNULIB'.

`\gnu\include'
     for the header files. The preprocessor finds the include file in
     this directory by looking up the environment variable `GNUINC'.

   With earlier versions of GNU CC it was only allowed to put one path
into the variables `GNULIB' and `GNUINC'. GCC 1.37 and later allows you
to put several paths into these variables, which are separated by
either a `,' or a `;'. All the mentioned paths are searched in order to
locate a specific file. However the startup module `crt0.o' is *only*
looked for in the first directory specified in `GNULIB'. If the
preprocessor can't find a include file in one of the directories
specified by `GNUINC', it will also search the paths listed in `GNULIB'.


Installing the Executables
===========================

   The compressed archive of the GNU C compiler binary distribution
contains the 'common' executables of the GNU compiler. That means the
compiler driver (`gcc.ttp'), the preprocessor (`gcc-cpp.ttp'), the main
body (`gcc-cc1.ttp'), the assembler (`gcc-as.ttp') and the linker
(`gcc-ld.ttp'), but depending from where you got your GCC the packaging
might be different. The just mentioned programs are the absolute
minimum. To be comfortable, you should get the following support
programs:

`gcc-ar.ttp'
     is the object library maintainer.

`gdb.ttp'
     is the GNU debugger 2.6 modified for the Atari ST. John Dunning
     did the original port to the Atari. Since then Jwahar Bammi has
     extensively hacked it. GDB now uses DBX debugging information in
     the object files. This requires an assembler with version 1.36 or
     greater.

`sym-ld.ttp'
     creates the symbol file needed with GDB.

`gcc-nm.ttp'
     prints the symbols of a GNU object library or an object file.

`cnm.ttp'
     prints the symbol table of a GEMDOS executable.

`fixstk.ttp'
`printstk.ttp'
     are used to modify and print the current stack size of an
     executable.

`toglclr.ttp'
     TOS 1.4 users can toggle the clear above BSS to end of TPA flag
     for the GEMDOS loader. A newer version of `toglclr.ttp' also allows
     to toggle the loader bits, that were introduced with TOS versions
     2.x and 3.x.

`size68.ttp'
     This program list the values of the TEXT, DATA, and BSS sections
     of a ready to run executable.

`xstrip.ttp'
     removes the symbol table from an executable.

   All this files should go in `\gnu\bin\' directory on your gnu disk.
I personally keep my executables in the directory `e:\gnu\bin'. You
should than extend the search path of your CLI to include this
directory or you move the compiler driver `gcc.ttp' and the files,
which are *not* invoked by `gcc.ttp' (`gcc.ttp' calls `gcc-cpp.ttp',
`gcc-cc1.ttp', `gcc-as.ttp' and `gcc-ld.ttp') into the directory, where
you keep your other executables. The next step is to actually define
`GCCEXEC'. `gcc.ttp' uses this variable to locate the preprocessor,
compiler, assembler and the linker. `GCCEXEC' contains a
device/dir/partial-pathname, which not only consists of the directory,
where the executables are kept, but also a common prefix, which is
`gcc-'. Assuming you also put the executables in the directory as
described above, `GCCEXEC' would contain `e:\gnu\bin\gcc-'. The value
is the same, you would give the compiler driver with the `-B' option.

   Then you should define a variable called `TEMP'. During compilation
the output of the various intermediate stages is kept here. The
variable must *not* contain a trailing backslash. If you have enough
memory, `TEMP' should point to a ramdisk.


Installing the libraries
=========================

   The next thing to do is to install the libraries. The distributed
archive contains the following libraries (again, the packaging may
vary):

`crt0.o'
`gcrt0.o'
     are the startup object modules. The file `gcrt0.o' instead of
     `crt0.o' is used, if the sources files are compiled for execution
     profiling (the `-pg' option).

`gnu.olb'
`gnu16.olb'
     are the standard libraries, the usual `libc' on other systems.

`curses.olb'
`curses16.olb'
     are ports of the BSD curses.

`gem.olb'
`gem16.olb'
     contain the Atari ST Aes/Vdi/FSM-GDOS bindings.

`iio.olb'
`iio16.olb'
     contain the integer only `printf' and `scanf' functions.

`pml.olb'
`pml16.olb'
     are the portable math libraries.

`termcap.olb'
`termcap16.olb'
     are for the pure `termcap' support.

`widget.olb'
`widget16.olb'
     are a small widget based on `curses'

   All these libraries go to a place described by the environment
variable `GNULIB'. Again this variable must *not* contain a trailing
backslash. Staying with the above example, I've set the variable to
`e:\gnu\lib'. The libraries, which have a 16 in their names were
compiled with the `-mshort' option. This makes integers the same size
as shorts.

   If you like to write programs for MiNT, the TOS multitasking
extension from E.R.Smith, you might consider to replace `gnu.olb',
`gnu16.olb', `iio.olb' and `iio16.olb' with the libraries supplied by
Eric Smith. The source and the binaries of these libraries can also be
retrieved from the Atari archive at terminator. The files are
`mntlibXX.zoo' for the sources and `mntolbXX.zoo' for the binaries.
They are found in the `mint' directory. XX is the version number,
currently 20. Programs written with this libraries will also run under
TOS, as long no MiNT specific features have been used. (*Note The
C-Compiler Driver::, for more info on compiling programs for MiNT (the
`-mint' option))

   Another option is to have both sets of libraries installed. For this
you have to rename the MiNT libraries according to the following scheme:

   * `crt0.o' => `mcrt0.o'

   * `gcrt0.o' => `mgcrt0.o'

   * `gnu.olb' => `mint.olb'

   * `gnu16.olb' => `mint16.olb'

   To select these files instead of the standard TOS versions and to
activate the MiNT specific portions of the header files you have to
include the `-mint' option in the `gcc.ttp' command line.


Installing the Header Files
============================

   The last bit to install are the header files. They are contained in
an archive of their own. The preprocessor now knows about the variable
`GNUINC'. Earlier version had to use the `-IPREFIX' option, to get to
the header files. According to the above examples, the files would be
put in the directory `e:\gnu\include'. `GNUINC' has to be set
accordingly.

   If you like to write programs for MiNT, apart from the libraries you
also need the MiNT specific include files (also from the Atari archive).
These are found in the archive `mntincXX.zoo' in the `mint' directory.
XX matches the version number of the library. (*Note The C-Compiler
Driver::, for more info on compiling programs for MiNT (the `-mint'
option)).

   If you choose to have both sets of libraries installed you can keep
the TOS specific header files since they are compatible with the MiNT
ones.


Gulam Notes
============

   The programs, which come with the GCC distribution also understand
filenames, which use the slash (`/') as a separator. When Gulam is your
favorite CLI you will stick to the backslashes, since you otherwise
lose the feature of command line completition.

   If you are using Gulam, you can define `aliases' to reach the
executables under more common names.

     alias cc e:\gnu\bin\gcc.ttp
     alias ar e:\gnu\bin\gcc-ar.ttp
     alias as e:\gnu\bin\gcc-as.ttp
     alias ld e:\gnu\bin\gcc-ld.ttp
     ...

   Now you should be able to say `cc foo.c -o foo.ttp' and the obvious
thing should happen. If you still have trouble, compare your settings
with the ones from the sample file `gulam.g'. That should give you the
right idea.

   One additional note to Gulam. `crt0.o' is currently set up to
understand the MWC/Atari convention of passing long command lines
(except it doesn't look into the `_io_vector' part). Gulam users should
set `env_style mw', if you want to give long args lines to `gcc.ttp'.

   To summarize the above, here are the settings from my `gulam.g'
initialization file. The usage of `UNIXMODE' environment variable is
explained in the file `unixmode.doc', which is part of the library
sources. The `GXXINC' variable is for G++.

     set env_style mw
     setenv TEMP i:
     setenv PATH e:\gnu\bin;<your other search paths here>
     setenv GCCEXEC e:\gnu\bin\gcc-
     setenv GNULIB e:\gnu\lib
     setenv GNUINC e:\gnu\include
     setenv GXXINC e:\gnu\g++-inc
     setenv UNIXMODE 'd/brG'


Installing G++
***************

   For the G++ installation apply the same rules as for the GCC
installation. The G++ compiler driver `g++.ttp' and the actual compiler
`gcc-cc1+.ttp' belong into the same directory as the GCC executables.
The preprocessor is shared between G++ and GCC. The library `g++.olb'
goes into the same directory as all the other libraries. Since G++ has
a complete set of include files of it's own, they all should be copied
into the directory `\gnu\g++-inc'. To let the preprocessor know, where
it can find the include files, the variable `GXXINC' is used.

   The above is valid for G++ 1.xx. Since GCC and G++ were merge into
one large package with version 2.x, there is no longer a special
compiler driver for G++. `gcc.ttp' determines from the file extension,
whether the C or C++ compiler should be invoked. The file
`gcc-cc1plus.ttp' is the actual C++ compiler. This file name is usually
truncated to `gcc-cc1p.ttp' in the 8+3 TOS file system. What is said
about the include files and the variable `GXXINC' is also true for G++
2.x.

   To actually use G++, some requirements have to be fulfilled. You need
the GCC include files and libraries with at least patch level 72.
Additionally the linker `gcc-ld.ttp' must have at least patch level 22.

   The library `g++.olb' is at the moment not 100% 16bit clean. That
means, there is at the moment no version, which is compiled with the
`-mshort' option.


Memory Requirements
********************

   GCC loves memory. A lot. It loves to cons structures. Lots of them.
Earlier versions probably won't run at all in less than 1 Meg; the
version 1.36 of GCC will probably need 2 Meg. The `gcc-cc1.ttp' had 1/2
meg stack, and needs it for compiling large files with optimization
turned on. Happily, it doesn't need all that stack for smaller files, or
even big files without the `-O' option, so it should be feasible to
make a compiler with a smaller stack (with `fixstk.ttp').

   GCC versions 1.37 and later uses another scheme for memory
allocation. The programs `gcc-cpp.ttp' and `gcc-cc1.ttp' are setup for
`_stksize == -1L'. This means, that an executable will use all
available memory, doing mallocs from internal heap (as opposed to the
system heap via `Malloc'), with `SP' initially set at the top, and heap
starting just above the `BSS'. So if the compiler runs out of memory,
you probably need more memory (or get rid of accessories, tsr's etc and
try).

   During my compilation of TeX 3.1 on my ST, I found that the size of
a source file is not main the limiting factor, but the size of a
function. At that time my ST was equipped with 2.5 megs of memory. About
512 Kb was used for ramdisk, cache and some auto folder programs. With
this configuration the maximum size of a function, which could be
compiled, was about 14-20 KB depending on how much code was inlined.
Additionally I was able to compile GCC 1.40 and GAS 1.38 on my ST, but
for this I had nearly disable every program in the auto folder. So, with
GCC 1.40 you're doing fine with at least 2.5 megs.

   With GCC 2.2 you definitly need more memory. The compiler executable
itself is about 850 Kb in size. The C++ compiler is even larger (about
1.1 Mb). So, with GCC 2.2 you should have 4 Mb.
============================================================
--
MfG/Regards

     /====                          Siemens Nixdorf Informationssysteme AG
    /    Ridderbusch        / ,    Abt.: STO SI211
   /                       /./    Riemeke Str.
  /=== /,== ,===/  /,==,  //     W-4790 Paderborn, Germany
 /    //   /   /  //   / / \    Tel.: (49) 05251-8-0
/    /     `==/\ /    / /   \  NERV:ridderbusch.pad

Email: ridderbusch.pad@sni-usa.com (America (North & South))
       ridderbusch.pad@sni.de      (Rest of world)