CC(1) USER COMMANDS CC(1) NAME cc - Sozobon C Compiler Driver eXtended version SYNOPSIS cc [options] files cc [-h][-cOSEvVnpdfmt][-W ][-e |-ef |-es] ][-s ][-l ] [-nostdlibs ][-F ][-o ][-sdir ][-odir ] [-L ][-I ][-D ][-U ][-X[n][func] ] [+P ][+C ][+O ][+A ][+L ][-u ] [] []... DESCRIPTION This eXtended version of Sozobon compiler driver uses a command syntax like a lot of C compilers (esp Unix) The cc command runs the passes of the compiler as needed to process files given on the command line. Various options exist to control the execution of cc or the compiler passes it runs. When you invoke cc, it normally does compilation, assembly and linking, but not preprocessing. Sozobon has an internal preprocessor. File names which end in .c are taken as C source to be compiled or preprocessed; file names ending in .i are taken as preprocessor output to be compiled; compiler output files plus any input files with names ending in .s are assembled; then the resulting object files, plus any other input files, are linked together to produce an executable. Command options allow you to stop this process at any intermediate stage. cc recognizes file names with the following suffixes: .c C source file .i preprocessor output file (made from C source file) .tmp Assembly language input for optimizer .cpp Assembly language input for preprocessor .s Assembly language input for assembler .o Relocatable object module .a Library module .lib Library module With no suffix specified a library or object module is assumed. The name of the executable is based on the first file name seen on the command line. If the first file name was "foobar.c", the executable would be named "foobar.out". By default every file, generated during a compile pass, is deleted after succesfull generating the next output from it. But '.o' files and executables are never deleted, except the pass to generate them failed. (This changed a little bit, cause keeping '.o' files for a executable made from a single source file makes no sense!) A lot of command options allow you to control cc itself, others are passed to the called programs. Some options may not grouped in the command line, some are switches to identify a filename, etc.. OPTIONS First the options to control the overall compilation process, including those that say whether to link, whether to assemble, and so on. -c Compile or assemble the source files, but do not link: Produce object files with names made by replacing .c or .s with .o at the end of the input file names. Do nothing at all for object files specified as input. -O Run the assembly optimizer between the compiler and assembler. This renames the generated '.s' files to '.tmp' and produces new, optimized '.s' files. -S Compile into assembler code but do not assemble. The assembler output file name is made by replacing .c with .s at the end of the input file name. Do nothing at all for assembler source files or object files specified as input. The optimizer is run of course too, if specified. Together with option '-c' cc will work following this option, but the files generated ('.tmp', '.s') are not deleted! -E Run only the C preprocessor. Preprocess all the C source files specified, Output file name is made by replacing '.c' with '.i' in input filename. For Sozobon has no stand-alone 'cpp', this option is only provided for copmatibility and to enable easy generating of preprocessed '.c' files as input for other tools. But of course this switch is not really compatible cause 'cpp' invoced with '-E' writes it's output to stdout normally. So it may change to real compatibility soon. Here follow some switches to control cc itself, the output files and the linker. -v Compiler driver program prints the commands it executes as it runs the preprocessor, compile, assembler and linker. -V Same as above, but the verbose option is passed to each program run, too. -h Print a help page and exit. -n This option includes -v, and makes cc doing nothing, except show you what it would do with the commandline got. A link file is created too, so you can see what will be done with a special commandline, you typed. -p This option enables runtime execution profiling. It is passed to the compiler as '-P', and forces the linker to use a different startup code and a special runtime library. -f This option tells ld to use a floating point library, and undefines the __printf and __scanf symbols when linking. So these symbols should be taken from the floating point library. If you don't need this, simply add the floating point library to the input files and don't specifiy the -f option. -X[][] This option forces the compiler and the precompiler to generate debug code. The optional is only valid for hcc. The ways the debug code works is of course compiler dependant, and will (still) differ for cpp and hcc. This option tells the linker to make use of a special startupcode ('debug_s.o'), too! -d This option is passed to top. See top. (works only with only original top, maybe changed in future) -W With this option set, the compiler is told to stop compiling after n error messages (warnings). -e Every program run by cc is told to write error messages in a file made by the programs name and the suffix 'err'. Of course this works only with programs cc knows how they deal error messages. So hcc will write to 'hcc.err' ... . Before every run the related errfile is removed. So the errfiles willl be always up to date. If after return from a run with value 0 the error file has any length cc will let you know this. If it has a length of 0 it is removed. -ef Same as -e but for each file processed a special error-file is used: so hcc is asked to write error messages to a file which name is build of the source filename with the suffix '.c_e', jas to '.s_e'. -es Same as -e with save-option, additionally. The error files are saved (copied) to files 'compile.err' and 'assemble.err'. (soon there will be a option -ec (errors, collect), where all error files are collected in a file 'compiler.err' or something like this. -sdir With this option the generated assembler files and all following ones are written to directory . -odir With this option the generated object code files are written to directory . -o This option is passed to the linker, and specifies the file where ld output goes in. By default it is made of the first's input filename, and the suffix '.out'. If there is none (-F option) it is 'a.out'. Together with the options '-c' or '-S' 'file' is taken as the name of the assembler output file. -F By default cc makes a link file to tell ld which files to link. This file is written to '$TMP\ldfile.tmp', and removed if the linker was successfull. This file contains libraries and objects according to commandline. If you want to control by yourself what the linker will link together, you can write a linkfile and specify it with the -F option. -s With this option you can specify a startup code, to be linked first, and used instead of the default one. (which is different for -p -X and -f option!) -l This is similiar to -s but it deals with the standard library. The one specified here will overwrite the default ones. -nostdlibs This switch inhibts use of any standard library files (startup codes, too), except the ones specified with -s and -l option: Nothing not in commandline gets linked. -L Path is added to the search list for libraries. -t The linker is told to generate a symbol table. -m The linker is told to generate a load map. The multiple Passes option -p is already used by profiling option, so you will have to type +L-p to tell the linker to rescan libraries. (perhaps I find a compatible option char for this in next version; what about -r or -rescan?) Some options are passed to the runs, and are not of interest in cc: The follwowing ones are passed to precompiler and compiler: -I add directory 'path' to the header search list -D define the pre-processor symbol 'sym' as 1 -D define the pre-processor symbol 'sym' as 'val' -U un-define the built-in symbol 'sym' Now there is one option left for the linker: -u It tells ld to undefine symbol , so it is linked from library. Here follow the options to pass any strings (options, arguments) to any run, started by cc. These options are prefixed with a '+' sign! They may contain any characters, but no whitespace ones. You can pass of course more than one options to every program using '+?' options. +P is passed to cpp. Example: '+P-C' will force cpp to write all comments to ouput file. cpp will get this as '-C' in it's commandline. +C is passed to hcc. +O is passed to top. +A is passed to jas. +L is passed to ld. FILES cc assumes to find any files in paths, declared in following environment variables. Some locations are predefined with annotated definitions: $PATH \bin,\sozobon\bin (path of executables) $LIB \lib,\sozobon\lib (path of libraries and objects) $INCLUDE \include,\sozobon\include (not used by cc itself) $TMP $SOZLIBS (additionally libraries and objects) $SOZBIN (path of executables) Single items are to sperate with ',' or ';'. Current directory is always assumed first. Any path mentioned in $LIB may contain a directory 'sozobon\', which is found by cc itself. So you needn't write setenv LIB "\\usr\\lib\\sozobon" in your shell, but setenv LIB "\\usr\\lib,\\usr\\otherlib" All files will be searched first in '\usr\lib\sozobon', then in '\usr\lib', in '\usr\otherlib\sozobon, and at last in '\usr\otherlib'. There will be changes in next version to this, cause I think there should be some MiNT support, too! $TMP is only used for the linkfile. If not set the current directory is used. $SOZLIBS may contain a list of libraries (and object files) to use as additional standard libraries. This feature/variable was added for all those who don't use make, where you can specify a variable $(LIBS) or $(LOADLIBES) which does the same. (For example: 'setenv SOZLIBS "initargv,aesfast,vdifast"') The order in linkfile is: First the startup file, the specified inputfiles (with the order in commandline), the files from $SOZLIB (same order), at last the built in standard libraries. The files from $SOZLIB are ignored with -nostdlibs switch, too! $SOZBIN may contain a single path or a list of directories, to find the executables (hcc, top, ...). You needn't set this environment variable, if the excutables are to find in $PATH. But if you keep your Sozobon-binaries in a special directory you should set this variable. It is used instead of $PATH if set; the default location is only used if $PATH is not set! filenames: FILE.c source code cpp preprocessor hcc compiler top optimizer jas assembler ld linker (in some future version you may overwrite these executable's names with environment variables) $TMP\ldfile.tmp linkfile (generated) a.out linker output (generated) libraries (the first found in a line is used): std_s.o, dstart.o startup code prof_s.o, pdstart.o startup code with -p option debug_s.o startup code with -X option xdlibs, dlibs standard library pdlibs, xdlibs, dlibs standard library with -p option float, libm additional math library used with -f option plibm, float, libm additional math library used with -fp options filename suffixes: .app, .ttp, .prg, .tos, .gtp, .c, .i, .tmp, .cpp, .s, .o, .a, .lib generated files: cpp: FILE.c -> FILE.i FILE.cpp -> FILE.s hcc: FILE.c -> FILE.s top: FILE.tmp -> FILE.s (during a pass FILE.s is first moved to FILE.tmp, so FILE.s is always the valid assembly language file) jas: FILE.s -> FILE.o ld: FILE.o -> FILE.out (using .o, .a, .lib) FILE may contain path specifications too, but cwd is always assumed. LIMITS: max number of options to pass to a program: 16 max libraries from environment $STDLIBS : 30 in cml: 30 max files each suffix: 200 (this will be changed in any next version to unlimited) SEE ALSO make(1), cpp(1), hcc(1), top(1), jas(1), ld(1). COPYING This is cc 1.01x5, an eXtended version, oct 93 by jerry g. geiger. I modified the version 1.01, Copyright (c) 1988 by Sozobon, Limited, to produce this one, to work with eXended versions of Sozobon C by Holger Weets, Christian Wempe und Frank Specht. It is still a part of Sozobon C compiler: The Sozobon C Compiler is a freeware offering from Sozobon, Limited Tony Andrews Johann Ruegg Joe Treat The Sozobon C Compiler is distributed in both binary and source form. The programs and code are copyrighted, but may be freely distributed. The only restrictions are: 1. No charge may be made other than reasonable charges for reproduction. 2. Modified versions must be clearly marked as such. 3. The authors are not responsible for any harmful consequences of using this software, even if they result from defects in it. Tony Andrews 4704 Berkshire Court Boulder, CO USA 80301 BUGS: No doubt, there are some. IF you find one please report to me: maus: Jerry Geiger @B internet: jerry@zelator.in-berlin.de. or: Jerry Geiger Tellstr 2 D 12045 Berlin