SDK Developer Tools

Introduction

The Software Development Kit (SDK) contains a suite of software tools to aid developers in making software for AmigaOS.

Tags

#Archiving	An archiving tool
#Building	A building tool
#Conversion	A conversion tool
#Debugging	A debugging tool
#Documenting	A documenting tool
#Localization	A localization tool
#Optimizing	An optimizing tool
#Testing	A Testing tool
#Versioning	A versioning tool

Format

The following lists the characters that indicate the type of argument shown in format listings. Do not use these characters as part of the command.

< >	Angle brackets indicate where additional information, such as a file name, must be included. This argument is required if it is not surrounded by square brackets. (For example, [<filename>]; see below.)
[ ]	Square brackets enclose optional arguments and keywords. Although not required, these arguments and keywords are accepted by the command.
{ }	Braces enclose items that can be given once or repeated any number of times. For example, {<args>} indicates that several items can be given for this argument.
|	Vertical bars separate lists of options from which you can choose only one. For example, [OPT R|S|RS] indicates a choice of the R option, the S option, or both options.
<n>	A numeric value is expected by the argument.
KEYWORD	An upper case keyword indicate that the argument's keyword is required if you include that argument.
...	An ellipsis (...) after a string argument indicates that the string must be the final argument on the command line. Including a comment is not allowed. The remainder of the command line is taken as the desired string. Quotation marks are not needed around the string, even if it contains spaces. If you enter quotation marks, they are part of the string. If you specify the keyword, you can put leading and trailing spaces in the string.
command line indentation	On command lines that are long enough to wrap to the next line, this manual shows the wrapped lines as indented for documentation purposes only. In practice, the wrapped lines align with the first character of the Shell prompt.

AutoDoc

Tags: #Documenting

AutoDoc extracts and sorts autodocs from the given files and prints them in the standard output.

Tool Types

(none)

Shell Usage

Format

AUTODOC [-t <number>] [-i] [-o] [-a] [-s] [-C] [-l <length>] [-w] [-c] [-f] [-r] [-F <file>] [-I] {<infile>}

Template

-t <number> -i -o -a -s -C -l <length> -w -c -f -r -F file -I {infile}

Location

SDK:C

The options are:

{<infile>}	List of files to be processed.
-t<number>	Turn tabulators to given number of spaces.
-i	Process only INTERNAL autodocs.
-o	Process only OBSOLETE autodocs.
-a	Do not process autodocs starting with an asterisk.
-s	Process autodocs starting with a semicolon.
-C	Process autodocs starting with "/*". This is the default setting.
-l<number>	Set the line length for the output. The default is 78.
-w	Turn off word wrapping.
-c	Do not convert "\*" to "/*" or "*\" to "*/".
-f	Do not add form feeds between the autodoc entries.
-r	Generate Troff source output.
-F<file>	Use <file> as a temporary file. The default temporary file is "tmpfile".
-I	Do not print "Table of Contents" before entries. If omitted, "Table of Contents" will be printed after the entries.

Example

Extract autodocs from files "main.c" and "functions.h" and redirect AutoDoc's output to file "MyDocs.doc".

1> autodoc -a -C main.c functions.h >MyDocs.doc

ARexx Interface

AutoDoc has no ARexx interface.

BuildLanguageCT

Tags: #Localization

This tool generates a catalog translation file (CT file) from the current system language driver.

A new language.catalog can be created with a CatComp tool using the generated CT file and a language catalog descriptor file (located in "SYS:Locale-Source/language.cd").

Tool Types

(none)

Shell Usage

Format

BUILDLANGUAGECT

Template

(none)

Location

SDK:C

See also

• CatComp

Example 1

List the current language driver strings.

 1> BuildLanguageCT

Example 2

Create a "language.ct" file with the built-in strings of the current system language driver.

 1> BuildLanguageCT >language.ct

ARexx Interface

BuildLanguageCT has no ARexx interface.

BuildMapTable

Tags: #Localization

BuildMapTable converts Charset-To-Unicode mapping tables in text form (e.g. available at http://www.unicode.org/Public/MAPPINGS/) to mapping tables in binary form usable by diskfont.library.

BuildMapTable can either display a text form of the parsed table or create a binary mapping table in the "L:Charsets/" directory. Currently only 8-bit character set mapping tables are supported.

If "L:Charsets/character-sets" or "L:Charsets/custom-character-sets" contains a MIME name for an 8-bit character set where no mapping table in "L:Charsets/" does not exist, and you have a mapping table in text form, use BuildMapTable to create the binary mapping table and reboot (diskfont.library searches tables only once) to be able to use the new character set (e.g. in fonts or catalog files).

The expected format of text mapping tables is as follows:

• Anything from a '#' character to the end of a line is considered a comment.
• A valid line does contain the index on the left and the Unicode point at the right side, in either hexadecimal (starting with 0x or 0X) or octal (starting with 0) or decimal form, separated by empty space.

Example

0xA4 0x20AC # EURO SIGN

Tool Types

(none)

Shell Usage

Format

BUILDMAPTABLE <ASCII mapping table> [CHARSET]

Template

UNICODEMAPTABLE/A,CHARSET/K

Location

SDK:C

The parameters are:

UNICODEMAPTABLE	A character set mapping table file.
CHARSET	A MIME character set name or alias.

The UNICODEMAPTABLE parameter specifies a character set mapping table file to be read and the CHARSET parameter the binary mapping table file to be written.

The MIME character set name obtained from diskfont.library will be used as file name of the binary character set mapping table which will be stored in "L:Charsets/". If the CHARSET parameter is omitted, no file will be written, instead the resulting mapping table is displayed in text form.

Example 1

Parse a text file "CP1258.TXT" and display a list of entries with the index on the left and the Unicode codepoint at the right side.

 1> BuildMapTable CP1258.TXT

Note: unmapped entries (with Unicode codepoint 0) are not displayed.

Example 2

Parse a text file "8859-1.TXT" and create a file "L:Charsets/ISO-8859-1" (latin1 is an alias for ISO-8859-1).

 1> BuildMapTable 8859-1.TXT CHARSET LATIN1

ARexx Interface

BuildMapTable has no ARexx interface.

BumpRev

Tags: #Versioning

BumpRev updates version and revision information and makes this available for program code to use it. It generates header file for C and Assembly language programs to use. The typical application is to "bump" (i.e. increment) the revision number of a program, library, device, etc. after it has been changed and before it is released.

There are two common practices to use BumpRev:

1. Update the revision number whenever the software is rebuilt
2. Update the revision number only when a new release is created

The advantage of a. is that you can integrate it into your built process, and you won't ever forget to bump a revision number when something has changed. The disadvantage is that revision numbers can increase very quickly (do not worry: you have 65535 revisions to spare).

The advantage of b. is that it saves revision numbers (which can become scarce), but the disadvantage is that you might forget to bump a revision number before you rebuilt a new release.

Practice a. has a lot going for it, and it was the preferred default at Commodore when AmigaOS 2.x/3.x were created.

Tool Types

(none)

Shell Usage

Format

BUMPREV [-q] [-v <version>] [-r <revision>] [-n <name>] [-b <base name>] [-d <depend list file>]

[-e <exclude suffix>] [-i <include suffix>] [-D] [-L] [<version> <base name> [<depend list file>]]

Template

-q -v <version> -r <revision> -n <name> -b <base name> -d <depend list file>

-e <exclude suffix> -i <include suffix> -D -L <version> <base name> <depend list file>

Location

SDK:C

The options are:

-q	Activate "quiet" operation, i.e. will not print any warning or progress messages, but will print error message.
-v <version>	Set the version number to use. This must be a number greater than 0. Note that version numbers greater than 255 are unsafe to use for some applications since a "struct Resident" only reserves an unsigned 8-bit integer for storing a version number in it.
-r <revision>	Set the revision number to use rather than let BumpRev read and increment it instead. This must be a number greater than 0.
-n <name>	Set the name of the program, library, device, etc. If it is not the same as the base name (see below). This can be useful for software built on systems which do not use a case-insensitive file system
-b <base name>	Set the base file name all the work and header file names are generated from. This also becomes the name that is written to the files unless you override this with the -n option (see above).
-d <depend list file>	A file which contains a list of file names whose modification times should be compared against the modification time of the file which contains the revision number. If any of these files has been modified after the revision number file has a new revision will be created; otherwise BumpRev will exit immediately. There must be one file name per line. Note that if you give "-" as the file name, BumpRev will try to read the file name list from standard input.
-e <exclude suffix>	By default BumpRev generates three header files: one for use with C and two for use with Assembly. language The C header file name ends with ".h" and the two Assembly language file names end with ".i" and ".s", respectively. You can tell BumpRev not to create all of these files with the -e option.
-i <include suffix>	This controls which header files should be created, with the default being the ".h", ".i", and ".s" files. The difference between the -i option and -e option is that with -i you say exactly what header files you want, and not what you do not want.
-D	Add a DEVNAME definition to the output files.
-L	Add a LIBNAME definition to the output files.

You can specify the base name, the version number and the dependencies file name both using options and as regular parameters. But you do not need to specify both. For example, the following commands are equivalent:

  BumpRev -b foo 1
  BumpRev 1 foo
  BumpRev -v 1 foo
  BumpRev -v 1 -b foo

The following commands are equivalent, too:

  BumpRev 1 bar dependencies_file
  BumpRev -b bar 1 dependencies_file
  BumpRev -v 1 -d dependencies_file bar
  BumpRev -v 1 -b bar dependencies_file

Example 1

Create or update a revision file "foo_rev.rev" unless it already exists, and create three more header files: "foo_rev.h", "foo_rev.1", and "foo_rev.s".

  1> BumpRev 1 foo
  BumpRev: Creating new file "foo_rev.rev"
  BumpRev: Bumped "foo" to version 1.1.

If you invoke BumpRev with the same parameters again, the revision file will be updated, incrementing the revision number. The three header files will be updated, too.

  1> BumpRev 1 foo
  BumpRev: Bumped "foo" to version 1.2.

Example 2

The name you give BumpRev goes into the names of the header files, and it also becomes the name printed in each string. This can be overridden with the -n option.

  1> BumpRev -n Bar 1 bar
  BumpRev: Creating new file "bar_rev.rev".
  BumpRev: Bumped "Bar" to version 1.1.

The resulting files still use the same base name, but the names printed in the files are different.

bar_rev.h

#define VERSION  1
#define REVISION 1
#define DATE     "15.6.2020"
#define VERS     "Bar 1.1"
#define VSTRING  "Bar 1.1 (15.6.2020)\r\n"
#define VERSTAG  "\0$VER: Bar 1.1 (15.6.2020)"

Example 3

BumpRev defaults to create three header files, but at times there may be only one you need. To create just the C language header file, you would use the -e option like this:

  1> BumpRev -e si 1 baz

This would create only "baz_rev.h" and omit "baz_rev.i" and "baz_rev.s".

ARexx Interface

BumpRev has no ARexx interface.

CatComp

Tags: #Localization

CatComp is a program to handle the creation and maintenance of the message catalogs used by locale.library. Message catalogs are IFF files read by locale.library that contain all the text strings used by an application. By providing several of these catalog files, an application can use locale.library and transparently adapt itself to the user's preferred language.

CatComp reads and processes two kinds of input files, and produces five types of output files.

CatComp Input Files

The first kind of file read by CatComp is a catalog description file. That file describes all the strings used by an application. There is one such file per localized application. In this file, you assign numbers to all the application strings as well as specify their minimum and maximum lengths.

The second kind of file read by CatComp is a catalog translation file. That file contains all strings from the application translated to one language. There is one catalog translation file per language supported by a localized application.

CatComp Output Files

CatComp can produce several different kinds of output files. The first is an IFF catalog. These are regular IFF files. There is one catalog produced for every catalog text file successfully processed. Catalogs are read directly by locale.library whenever the OpenCatalog() call is made.

The second type of file output by CatComp is an empty translation file. This is useful when starting a translation. It lets CatComp convert a catalog description file into a ready to fill-in translation file.

The third type of file output by CatComp is a new translation file based on an old one. This is useful when re-starting a translation after a catalog description file was modified, because the new and the modified strings will be stored in the the new catalog translation file.

The fourth and fifth type of files output by CatComp are C and Assembly language programming source files. These are used by application writers to convert catalog description files into source files that can be directly used in their applications.

The sixth and seventh type of files output by CatComp are Modula-2 language definition and implementation source files, which are used by programmers in much the same way C and Assembly files are used.

Finally, the last type of file output by CatComp is an AmigaDOS load file. These load files are used by application writers to include a set of strings directly inside an application. This is normally used to encode the default strings that an application uses when there are no external catalogs available.

File Formats

To learn more about CatComp's input and output files, consult CatComp documentation located in the Software Development Kit: SDK:Documentation/Tools/Locale/CatComp.doc.

Tool Types

(none)

Shell Usage

Format

CATCOMP <descriptor> [<cd file>] [CATALOG=<catalog file>] [CTFILE=<ct file>] [CFILE=<c source file>]

[SYMBOLS={<symbol>}] [VERBOSITY=<verbosity level>] [NOOPTIM] [NONUMBERS] [NOSTRINGS] [NOARRAY]

[NOBLOCK] [NOCODE] [SORT] [COMMENTS]

Template

DESCRIPTOR/A,TRANSLATION,CATALOG/K,CTFILE/K,CFILE/K,SYMBOLS/M/K,VB=VERBOSITY/N/K,NOOPTIM/S,

NONUMBERS/S,NOSTRINGS/S,NOARRAY/S,NOBLOCK/S,NOCODE/S,SORT/S,COMMENTS/S

Location

SDK:C

The options are:

DESCRIPTOR	Specifies the name of a catalog descriptor file. Typically, the file extension for catalog descriptor files is ".cd".
TRANSLATION	Specifies the name of a catalog translation file. Typically, the file extension for catalog translation files is ".ct".
CATALOG	Specifies the name of the IFF catalog file to produce. When this option is specified, a translation file must have been given in the previous argument.
CTFILE	Specifies the name of the catalog translation file to produce. This option only requires a catalog descriptor file be provided, then the catalog translation file will be blank. When you also specified a source translation file, the version string, language, codeset, and strings of the source translation file will be copied to the new translation file.
CFILE	Specifies the name of the C language source file header to produce. This option only requires a catalog descriptor file be provided, there is no need for a translation file.
SYMBOLS	Specifies any number of symbols that are used for determining which section of the available strings get included within generated C, Assembly, and object files. The valid symbols are: Symbol Description CATCOMP_NUMBERS This symbol causes the name of each string to be defined with the value of its ID, as listed in the catalog descriptor file. CATCOMP_STRINGS This symbol causes each string to be defined. CATCOMP_ARRAY This symbol causes a table of CatCompArray structure to become available. CATCOMP_BLOCK This symbol causes a compact table of all strings and their ID values to be generated. CATCOMP_CODE This symbol causes the generation of source code for a function called GetString().
VB or VERBOSITY	Specifies the amount of information CatComp should output while doing some processing. The lower this number, the less CatComp will output messages. Verbosity Level Description 0 No warnings 1 At verbosity level 1 or higher, warnings about C language formatting commands and warnings about missing strings in catalog translation files can appear. 2 At verbosity level 2 or higher, warnings about missing trailing ellipsis (...) in catalog descriptor files can appear. 3 At verbosity level 3 or higher, warnings about trailing blank characters and non-ASCII characters in catalog descriptor files can appear. This is the default verbosity level. 4 At verbosity level 4 or higher, CatComp will output every message it could. This includes warnings about identical strings in catalog descriptor and catalog translation files (which are not shown when the NOOPTIM switch was spesified).
NOOPTIM	When generating a catalog file, CatComp normally skips strings that are identical in the catalog descriptor file and in the catalog translation file and does not include them in the generated catalog file. This option disables this optimization.
NONUMBERS	This option is only useful when generate C or Assembly language header files. It prevents the generation of the CATCOMP_NUMBERS section within the header file.
NOSTRINGS	This option is only useful when generate C or Assembly language header files. It prevents the generation of the CATCOMP_STRINGS section within the header file.
NOARRAY	This option is only useful when generate C or Assembly language header files. It prevents the generation of the CATCOMP_ARRAY section within the header file.
NOBLOCK	This option is only useful when generate C or Assembly language header files. It prevents the generation of the CATCOMP_BLOCK section within the header file.
NOCODE	This option is only useful when generate C or Assembly language header files. It prevents the generation of the CATCOMP_CODE section within the header file.
SORT	When specified, all strings will be sorted by ID before they are written to header/assembler/object/catalog files. Catalog translation files will, however, get written in the same order in which the strings showed up in the catalog descriptor file.
COMMENTS	When both this switch and CTFILE were spesified, the comment lines from the catalog description file will be copied into the new catalog translation file.

Example 1

Test if "app.cd" is a valid catalog descriptor file.

  1> CatComp app.cd

Example 2

Generate a blank translation file called "app.ct".

  1> CatComp app.cd CTFILE app.ct

Example 3

Create a catalog file "app.catalog".

  1> CatComp app.cd app.ct CATALOG app.catalog

ARexx Interface

CatComp has no ARexx interface.

ChangeRegs

Missing description.

Tool Types

(none)

Shell Usage

Format

CHANGEREGS <source file> <destination> [HEADER] [NEWSUFFIX=<file extension>]

Template

SRC=SOURCE/A,DEST=DESTPATH,HEADER/S,NS=NEWSUFFIX/K

Location

SDK:C

The parameters are:

SRC or SOURCE	C source code file to be processed.
DEST or DESTPATH	Path to directory where the processed source code will be saved.
HEADER	Add register definitions for SAS/C and GNU/C at the beginning of the source code.
NS or NEWSUFFIX	Save the processed source code with a new file extension.

ARexx Interface

ChangeRegs has no ARexx interface.

DistCC

Tags: #Building

DistCC is a program to distribute builds of C or C++ code across several machines on a network. It does not require all machines to share a filesystem, have synchronized clocks, or to have the same libraries or header files installed. They can even have different processors or operating systems if cross-compilers are installed.

DistCC is not itself a compiler, but rather a front-end to the GNU C/C++ compiler (GCC), or another compiler of your choice. All the regular GCC options and features work as normal.

For each job, DistCC sends the complete preprocessed source code and compiler arguments across the network from the client to a compilation server. Compilation is driven by a client machine, which is typically the developer's workstation. The DistCC client runs on this machine, as does Make, the preprocessor, the linker, and other stages of the build process. Any number of volunteer machines act as compilation servers and help the client to build the program by running the DistCCD daemon, C compiler and assembler as required.

DistCC runs across TCP sockets (on port 3632 by default). For TCP connections the volunteers must run the DistCCD daemon directly.

DistCC is intended to be used with GNU Make's -j option, which runs several compiler processes concurrently. DistCC spreads the jobs across both local and remote CPUs. Because DistCC is able to distribute most of the work across the network, a higher concurrency level can be used than for local builds. As a rule of thumb, the -j value should be set to about twice the total number of available server CPUs but subject to client limitations. This setting allows for maximal interleaving of tasks being blocked waiting for disk or network IO.

It is strongly recommended that you install the same compiler version on all machines participating in a build. Incompatible compilers may cause mysterious compile or link failures.

Environment Variables

DistCC uses the following environment variables:

Variable	Description
DISTCC_DIR	Path to the host list and locks files.
DISTCC_HOSTS	Name of the host list file. The default name is "hosts".
DISTCC_LOG	Name of the log file. When set, DistCC writes its output to the log.
DISTCC_VERBOSE	Setting this to 1 enables debug messages.

Server Specification

A list of servers will be taken from a file pointed by an environment variable $DISTCC_HOSTS or $DISTCC_DIR/hosts. In the file each host can be given in any of these forms:

Host Address / Command	Description
localhost	Run in place.
<host>	TCP connection to a specified host's port 3632.
<host>:<port>	TCP connection to a specified host's port number <port>.
--randomize	Randomize the server list before execution.

Tool Types

(none)

Shell Usage

Format

DISTCC [--help] [--version] [--show-hosts] [-j] [<compiler>] [<compiler options>]

Template

--help --version --show-hosts -j <compiler> <compiler options>

Location

SDK:C

Tutorials

• Distributed Compile on AmigaOS

See also

• DistCCD
• GCC
• GMake
• Make

The options are:

--help	Explain DistCC usage and exit.
--version	Show DistCC version and exit.
--show-hosts	Show host list and exit.
-j	Calculate the concurrency level from the host list.
<compiler>	Compiler to use. Defaults to cc.
<compiler options>	Compiler options. As a minimum, you should supply a list of source files to be compiled.

ARexx Interface

DistCC has no ARexx interface.

DistCCD

Tags: #Building

DistCCD is the server for the DistCC distributed compiler. It accepts and runs compilation jobs for network clients. DistCCD will listen for network connections and fork several child processes to serve them.

Environment Variables

DistCCD uses the following environment variables:

Variable	Description
DISTCC_CMDLIST	If the environment variable DISTCC_CMDLIST is set, load a list of supported commands from the file named by DISTCC_CMDLIST, and refuse to serve any command whose last DISTCC_CMDLIST_MATCHWORDS last words do not match those of a command in that list.
DISTCC_CMDLIST_NUMWORDS	The number of words, from the end of the command, to match. The default is 1.
DISTCCD_PATH	When starting distccd, if this value is set it will be used unaltered for the command-execution path. The code that normally tries to remove masquerade directories from the path is skipped.
DISTCC_SAVE_TEMPS	If set to 1, temporary files are not deleted after use.
DISTCC_TCP_DEFER_ACCEPT	Turn on the TCP_DEFER_ACCEPT socket option. Defaults to on.
TMPDIR	Directory for temporary files such as preprocessor output.

Tool Types

(none)

Shell Usage

Format

DISTCCD [--help] [--version] [-P=--pid-file <file>] [-N=--nice <level>] [--user <user>] [-j=--jobs <limit>] [--job-lifetime <seconds>]

[-p=--port <port>] [--listen <address>] -a=--allow <ip/bits> [--stats] [--stats-port <port>]

[--log-level <level>] [--verbose] [--no-detach] [--log-file <file>] [--log-stderr] [--wizard]

[--inetd] [--daemon]

Template

--help --version -P=--pid-file <file> -N=--nice <level> --user <user> -j=--jobs <limit> --job-lifetime <seconds>

-p=--port <port> --listen <address> -a=--allow <ip/bits> --stats --stats-port <port>

--log-level <level> --verbose --no-detach --log-file <file> --log-stderr --wizard

--inetd --daemon

Location

SDK:C

Tutorials

• Distributed Compile on AmigaOS

See also

• DistCC

The options are:

Option	Type	Description
--help	General	Display usage information and exit.
--version	General	Show version and exit.
-P <file> or --pid-file <file>	General	Save DistCCD process id to file <file>.
-N <niceness> or --nice <level>	General	Makes the DistCCD more nice about giving up the CPU to other tasks on the machine. <niceness> is an increment to the current priority of the process. The range of priorities depends on the operating system but is typically 0 to 20. By default the niceness is increased by 5.
--user <user>	General	Change user to <user>.
-j <limit> or --jobs <limit>	General	Sets a limit on the number of jobs that can be accepted at any time. By default this is set to two greater than the number of CPUs on the machine, to allow for some processes being blocked on network IO.
--job-lifetime <seconds>	General	Kills a DistCCD job if it runs for more than <seconds> seconds. This prevents denial of service from clients that don't properly disconnect and compilers that fail to terminate. By default this is turned off.
-p <port> or --port <port>	Networking	Set the TCP port to listen on, rather than the default of 3632.
--listen <address>	Networking	Instructs DistCCD to listen on the IP address <address>. This can be useful for access control on dual-homed hosts.
-a <ipaddr>[/<mask>] or --allow <ip/bits>	Networking	Instructs DistCCD to accept connections from the IP address <ipaddr>. A CIDR mask length can be supplied optionally after a trailing slash, e.g. 192.168.0.0/24, in which case addresses that match in the most significant <mask> bits will be allowed. This is a mandatory parameter.
--stats	Networking	Turn on the statistics HTTP server. By default it is off.
--stats-port <port>	Networking	Set the TCP port to listen on for HTTP requests, rather than the default of 3633.
--log-level <level>	Debugging	Set the minimum severity of error that will be included in the log file. Useful if you only want to see error messages rather than an entry for each connection. <level> can be critical, error, warning, notice, info, or debug.
--verbose	Debugging	Include debug messages in log. Equivalent to --log-level=debug.
--no-detach	Debugging	Do not detach from the shell that started DistCCD.
--log-file <file>	Debugging	Send messages to file <file>.
--log-stderr	Debugging	Send log messages to stderr. This is mainly intended for use in debugging.
--wizard	Debugging	Turn on all options appropriate for starting DistCCD under GNU debugger GDB.
--inetd	Operation Mode	Serve a client connected to stdin/stdout. Note: this option has been disabled.
--daemon	Operation Mode	Run DistCCD in the background.

Example

Start the server, allow connections from an IP address 192.168.1.100, and suppress all other messages except error messages.

  1> DistCCD --allow 192.168.1.100 --log-level=error

Pressing Ctrl + c stops the server.

ARexx Interface

DistCCD has no ARexx interface.

DistCCMon-Amiga

Tags: #Building

Displays the statuses of the current distributed compilation jobs graphically.

Tool Types

(none)

Shell Usage

Format

DISTCCMON-AMIGA

Template

(none)

Location

SDK:C

Tutorials

• Distributed Compile on AmigaOS

See Also

• DistCC
• DistCCD
• DistCCMon-Text

ARexx Interface

DistCCMon-Amiga has no ARexx interface.

DistCCMon-Text

Tags: #Building

Displays the statuses of the current distributed compilation jobs.

Tool Types

(none)

Shell Usage

Format

DISTCCMON-TEXT [<delay>]

Template

<delay>

Location

SDK:C

Tutorials

• Distributed Compile on AmigaOS

See Also

• DistCC
• DistCCD
• DistCCMon-Amiga

When run without parameters, DistCCMon-Text lists the current jobs and exits. If you want to continuously monitor the compilation jobs, supply a job polling delay. For example, to list the jobs in every 3 seconds type

  1> DistCCMon-Text 3

When you press Enter, DistCCMon-Text keeps listing the jobs until you interrupt it by pressing Ctrl + c.

ARexx Interface

DistCCMon-Text has no ARexx interface.

Expunge

Tags: #Debugging

Expunge is meant as a software developer tool to force shared libraries and devices to expunge themselves. The ramlib process is responsible for expunging libraries when the corresponding disk file has changed so there should be little need for this command in practice. The caching of system libraries and devices is normal and users should not be using this command.

Tool Types

(none)

Shell Usage

Format

EXPUNGE [{<library or device>}] [PATTERN <pattern>] [ALL]

Template

NAME/M,PAT=PATTERN/K,ALL/S

Location

SDK:C

Expunge with no arguments displays the list of devices and libraries along with their open count and flags. This is useful to find out the names of the objects to expunge.

Expunge will attempt to expunge the named shared libraries and/or devices. Since it is not possible to determine whether an expunge succeeds or fails Expunge will always state an object was expunged if it was found.

If PATTERN is specified only libraries and devices matching this pattern will be attempted to be expunged. This pattern may be an arbitrary DOS style pattern.

If the ALL switch is present Expunge will attempt to expunge all the shared libraries and devices with a usage count of zero. Any names specified will be ignored in this case.

If Expunge succeeded, the return code will be set to 0. If Expunge cannot find one or more specified names, it will continue and the return code will be 5. If Expunge fails completely, the return code will be 20. The secondary return code will be set appropriately.

Example 1

Display the current device and library lists.

  1> Expunge

Example 2

Expunge keyboard.device and graphics.library. Since the use count of these objects is greater than 0 nothing will happen but the command will still succeed. This is because there is no return code on the Expunge vector.

  1> Expunge keyboard.device graphics.library

Example 3

Expunge all the devices and libraries it can find.

  1> Expunge ALL

Example 4

Expunge all the unused catalogs and replace the obsolete Avail FLUSH technique.

  1> Expunge locale.library

Example 5

Expunge all libraries whose name is starting with "amiga" (i.e. amigaguide.library or amigaguide.datatype).

  1> Expunge PATTERN amiga#?

ARexx Interface

Expunge has no ARexx interface

FDTrans

Tags: #Conversion

FDTrans is a small utility for legacy SFD files. It offers two functions:

1. Convert an SFD file into an XML file for processing with the IDLTool
2. Generate 68k-to-PPC or PPC-to-68k cross call stubs. These are required to use a 68k Library from PPC code (automatically; implicit emulator calling works too but needs special attention) and to make a PPC library callable for (legacy) 68k programs.

FDTrans requires an SFD file as input. If you only have an FD file, you need to revert it to an SFD file using a tool like FD2Pragma.

Note
SFD file is a file which contains lines describing a library's entry points.

Note that for some SFD files it might be required to do some manual correction. Most notably, there is great commotion about the way that vararg functions are specified. The following format is used throughout because it is the most commonly used format:

VOID someFunc(ULONG someparam, ULONG Tag1, ...) (D0,A0)

Although this prototype doesn't really make sense (vararg functions are not supposed to list the first vararg argument), this is the way that FDTrans expects the functions in the SFD file. If you have a function like

VOID printf(char *format, ...) (A0,A1)

you need to manually add a dummy argument like

VOID printf(char *format, ULONG dummy, ...) (A0,A1)

For more information on FDTrans, see the developer documentation on migrating old programs and libraries.

Tool Types

(none)

Shell Usage

Format

FDTRANS <sfd file> [-o=--output <outfile>] [-i=--struct <structname>] [-l=--library <libname>]

[-x=--xml] [-s=--stubs] [-c=--c68k] [-cold] [-a=--all] [-6=--68k] [-4=--inline4] [-v=--verbose]

Template

<sfd file> -o=--output <outfile> -i=--struct <structname> -l=--library <libname> -x=--xml

-s=--stubs -c=--c68k -cold -a=--all -6=--68k -4=--inline4 -v=--verbose

Location

SDK:C

Tutorials

• How to Build Stubs for 68k Libraries

See Also

• IDLTool

The options are:

<sfd file>	An SFD file to process.
-o <outfile> or --output <outfile>	Use <outfile> as base for output files.
-i <structname> or --struct <structname>	Use <structname> as interface name. Guess name by default.
-l <libname> or --library <libname>	Use <libname> for OpenLibrary. Guess name by default.
-s=--stubs	Generate the PPC-to-M68k cross-call stubs in C.
-c=--c68k	Generate the M68k-to-PPC cross-call stubs in C.
-cold	Generate the M68k-to-PPC cross-call stubs in C but without TRAPTYPENR.
-a=--all	Generate the PPC-to-M68k and M68k-to-PPC cross-call stubs in C.
-6=--68k	Generate M68k-to-PPC cross-call stubs in Assembler.
-4=--inline4	Generate special inline4 for using M68k libraries without a PPC interface (interface pointer can be NULL).
-v=--verbose	Be verbose.

ARexx Interface

FDTrans has no ARexx interface.

FSTest

Tags: #Debugging

FSTest is a tool that checks for problems with a mounted file system on your computer. It can perform the following tests:

Test Number	Description
1	Add a notification.
2	Change the current mode of a lock.
3	Change the file mode.
4	Change the current file position.
5	Change the size of a file.
6	Close an open file.
7	Create a directory.
8	Create a hard link.
9	Create a soft link.
10	Delete a file, directory, or symbolic link.
11	Get information on a device.
12	Duplicating an existing lock.
13	Get a lock on an open file.
14	Reserved for a ExamineDir() test.
15	Examine a file.
16	Examine a locked file system object.
17	Reserved for FileSystemAttr() test.
18	Reserved for Flush() test.
19	Reserved for Format() test.
20	Reserved for GetFilePosition() test.
21	Obtain the size of a file.
22	Inhibit access to a filesystem.
23	Lock a directory or a file.
24	Lock a record (a portion of a file).
25	Open a file.
26	Open a file you have a lock on.
27	Obtain the parent directory for a directory or file lock.
28	Get a shared lock on the parent directory of a file.
29	Read data from a file.
30	Read the target object string for a filesystem soft link.
31	Change the volume name.
32	Remove notify.
33	Rename a file, directory, or symbolic link.
34	Reserved for SameFile() test.
35	Reserved for SameLock() test.
36	Reserved for Serialize() test.
37	Change a comment string on a filesystem object.
38	Set the modification date for a file or directory.
39	Set group for a file or directory.
40	Set owner for a file or directory.
41	Set protection for a file or directory.
42	Unlock a file or directory.
43	Unlock a locked record.
44	Reserved for VolumeInfoData() test.
45	Write data to a file.
46	Set a write protection status of a volume.

Tool Types

(none)

Shell Usage

Format

FSTEST <device> [NOINFOMESSAGES] [NOWARNMESSAGES] [NOROOTMESSAGES] [ABORTONERR]

[FIRSTTESTNUMBER <test number>] [LASTTESTNUMBER <test number>] [TESTNUMBER <test number>]

Template

DEVICE/A,NOINFOMESSAGES=NI/S,NOWARNMESSAGES=NW/S,NOROOTMESSAGES=NR/S,

ABORTONERR=AOE/S,FIRSTTESTNUMBER=FTN/K/N,LASTTESTNUMBER=LTN/K/N,TESTNUMBER=TN/K/N

Location

SDK:C

The options are:

DEVICE	Device to test.
NOINFOMESSAGES or NI	Do not show additional information on tests.
NOWARNMESSAGES or NW	Do not show warnings.
NOROOTMESSAGES or NR	Missing description.
ABORTONERR or AOE	Stop the execution of the test batch on first error.
FIRSTTESTNUMBER or FTN	First test to perform. The valid test number is between 1 and 45.
LASTTESTNUMBER or LTN	Last test to perform. The valid test number is between 1 and 45.
TESTNUMBER or TN	Perform a single test. The valid test number is between 1 and 45.

ARexx Interface

FSTest has no ARexx interface.

FSVPTool

Missing description.

Shell Usage

Format

Template

Location

SDK:C

GCC

Tags: #Archiving #Building #Debugging #Optimizing #Testing

The AmigaOS SDK contains essential tools from the GNU Compiler Collection and the GNU Binutils binary tools collection. The command line tools included in the SDK are:

• addr2line – Converts addresses into filenames and line numbers.
• ar – A utility for creating, modifying and extracting from archives.
• as – The GNU assembler.
• c++ – The GNU C++ compiler.
• c++filt – Filter to demangle encoded C++ symbols.
• cpp – The GNU C/C++ preprocessor.
• g++ – The GNU C++ compiler, c++ alias.
• gcc – The GNU C compiler.
• gccbug – A utility for filing a bug report.
• gcov – The GNU test coverage program.
• gprof – The GNU profiler.
• ld – The GNU linker.
• nm – Lists symbols from object files.
• objcopy – Copies and translates object files.
• objdump – Displays information from object files.
• ranlib – Generates an index to the contents of an archive.
• readelf – Displays information from any ELF format object file.
• size – Lists the section sizes of an object or archive file.
• strings – Lists printable strings from files.
• strip – Discards symbols.

The tools are located in the SDK:gcc/bin directory and the documentation can be found from the GCC and GNU web sites.

GDB

Tags: #Debugging

Missing description.

Shell Usage

Format

Template

Location

SDK:C

Tutorials

• GDB for Beginners

GMake

Tags: #Building

Missing description.

Shell Usage

Format

Template

Location

SDK:C

GUnZip

Tags: #Archiving

Missing description.

Shell Usage

Format

Template

Location

SDK:C

GZip

Tags: #Archiving

Missing description.

Shell Usage

Format

Template

Location

SDK:C

IDLTool

Missing description.

Shell Usage

Format

Template

Location

SDK:C

See Also

• FDTrans

Tutorials

• How to create an AmigaOS 4 library

ListDynDep

Missing description.

Shell Usage

Format

Template

Location

SDK:C

Localize

Tags: #Localization

Missing description.

Shell Usage

Format

Template

Location

SDK:C

Make

Tags: #Building

Missing description.

Shell Usage

Format

Template

Location

SDK:C

MakeAudioMode

Missing description.

Shell Usage

Format

Template

Location

SDK:C

ModList

Tags: #Debugging

Missing description.

Shell Usage

Format

Template

Location

SDK:C

SH

Missing description.

Shell Usage

Format

Template

Location

SDK:C

TAR

Tags: #Archiving

Missing description.

Shell Usage

Format

Template

Location

SDK:C

USBSnoop

Tags: #Debugging

Missing description.

Shell Usage

Format

Template

Location

SDK:C