NMCOLL(1) General Commands Manual NMCOLL(1)NAME
nmcoll - find name collisions in object files (2BSD)
nmcoll file ...
Nmcoll scans a set of object files as produced by the assembler (typically ending with .o) and produces a listing of suspicious name dupli-
cations. Nmcoll is useful when porting programs that were developed with compilers that support flex (long) names to 2.11BSD which only
supports seven significant characters in external names.
Nmcoll is a carryover from the era before longer symbol names were supported in object files.
SEE ALSO a.out(5)3rd Berkeley Distribution December 17, 1996 NMCOLL(1)
Check Out this Related Man Page
CC(1) General Commands Manual CC(1)NAME
cc - C compiler (2BSD)
cc [ option ] ... file ...
Cc is the UNIX C compiler. Cc accepts several types of arguments:
Arguments whose names end with `.c' are taken to be C source programs; they are compiled, and each object program is left on the file whose
name is that of the source with `.o' substituted for `.c'. The `.o' file is normally deleted, however, if a single C program is compiled
and loaded all at one go.
In the same way, arguments whose names end with `.s' are taken to be assembly source programs and are assembled, producing a `.o' file.
The following options are interpreted by cc. See ld(1) for load-time options.
-c Suppress the loading phase of the compilation, and force an object file to be produced even if only one program is compiled.
-w Suppress warning diagnostics.
-p Arrange for the compiler to produce code which counts the number of times each routine is called. If loading takes place, replace
the standard startup routine by one which automatically calls monitor(3) at the start and arranges to write out a mon.out file at
normal termination of execution of the object program. An execution profile can then be generated by use of prof(1).
-O Invoke an object-code improver.
-S Compile the named C programs, and leave the assembler-language output on corresponding files suffixed `.s'.
-M Run only the macro preprocessor on the named C programs, requesting it to generate Makefile dependencies and send the result to the
-E Run only the macro preprocessor on the named C programs, and send the result to the standard output.
-C prevent the macro preprocessor from eliding comments.
Name the final output file output. If this option is used the file `a.out' will be left undisturbed.
-Dname Define the name to the preprocessor, as if by `#define'. If no definition is given, the name is defined as "1".
-Uname Remove any initial definition of name.
-Idir `#include' files whose names do not begin with `/' are always sought first in the directory of the file argument, then in directo-
ries named in -I options, then in directories on a standard list.
-Ldir Library archives are sought first in directories named in -L options, then in directories on a standard list.
Find substitute compiler passes in the files named string with the suffixes cpp, c0, c1 and c2. If string is empty, use a standard
Find only the designated compiler passes in the files whose names are constructed by a -B option. In the absence of a -B option,
the string is taken to be `/usr/c/'.
Other arguments are taken to be either loader option arguments, or C-compatible object programs, typically produced by an earlier cc run,
or perhaps libraries of C-compatible routines. These programs, together with the results of any compilations specified, are loaded (in the
order given) to produce an executable program with name a.out.
file.c input file
file.o object file
a.out loaded output
/lib/c2 optional optimizer
/lib/crt0.o runtime startoff
/lib/mcrt0.o startoff for profiling
/lib/libc.a standard library, see intro(3)
/usr/lib/libc_p.aprofiling library, see intro(3)
/usr/include standard directory for `#include' files
mon.out file produced for analysis by prof(1)SEE ALSO
B. W. Kernighan and D. M. Ritchie, The C Programming Language, Prentice-Hall, 1978
B. W. Kernighan, Programming in C--a tutorial
D. M. Ritchie, C Reference Manual
monitor(3), prof(1), adb(1), ld(1), as(1)DIAGNOSTICS
The diagnostics produced by C itself are intended to be self-explanatory. Occasional messages may be produced by the assembler or loader.
The compiler currently ignores advice to put char, unsigned char, long, float, or double variables in registers.
3rd Berkeley Distribution June 7, 1985 CC(1)