<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<html>

<head>
<link HREF="http://drh.home.dyndns.org" REV="made" TITLE="David R. Hanson">
<title>Installing lcc</title>
</head>

<body>

<h1>Installing lcc</h1>

<p ALIGN="LEFT"><strong><a HREF="http://cwfraser.webhop.net">Christopher
W. Fraser</a> and <a HREF="http://drh.home.dyndns.org/">David R. Hanson</a>, <a
HREF="http://www.research.microsoft.com/">Microsoft Research</a></strong><br>
September 2002</p>

<h2>Contents</h2>

<ul>
  <li><a HREF="#intro">Introduction</a></li>
  <li><a HREF="#unix">Installation on UNIX</a></li>
  <li><a HREF="#driver">Building the Driver</a></li>
  <li><a HREF="#rcc">Building the Compiler and Accessories</a></li>
  <li><a HREF="#win32">Installation on Windows</a></li>
  <li><a HREF="#bugs">Reporting Bugs</a></li>
  <li><a HREF="#mailinglist">Keeping in Touch</a></li>
</ul>

<h2><a NAME="intro">Introduction</a></h2>

<p><a HREF="http://www.cs.princeton.edu/software/lcc/">lcc</a> is the ANSI C compiler
described in our book <cite>A Retargetable C Compiler: Design and Implementation</cite>
(Addison-Wesley, 1995, ISBN 0-8053-1670-1).</p>

<p>If you're installing lcc on a UNIX system, read the remainder of this section and
continue with the next section. If you're installing lcc on a Windows system, you should read the rest of this section, the following three sections, and the <a
HREF="#win32">Windows</a> section.</p>

<p>Extract the distribution into its own directory. All non-absolute paths below are
relative to this directory. The distribution holds the following subdirectories.</p>

<blockquote>
  <table BORDER="0" CELLPADDING="1" CELLSPACING="1" WIDTH="80%">
    <tr>
      <td><a HREF="../src"><code>src</code></a></td>
      <td></td>
      <td>source code</td>
    </tr>
    <tr>
      <td><a HREF="../etc"><code>etc</code></a></td>
      <td></td>
      <td>driver, accessories</td>
    </tr>
    <tr>
      <td><a HREF="../lib"><code>lib</code></a></td>
      <td></td>
      <td>runtime library source code</td>
    </tr>
    <tr>
      <td><a HREF="../cpp"><code>cpp</code></a></td>
      <td></td>
      <td>preprocessor source code</td>
    </tr>
    <tr>
      <td><a HREF="../lburg"><code>lburg</code></a></td>
      <td></td>
      <td>code-generator generator source code</td>
    </tr>
    <tr>
      <td><a HREF="../doc"><code>doc</code></a></td>
      <td></td>
      <td>this document, man pages</td>
    </tr>
    <tr>
      <td><code><a HREF="../include">include</a>/*/*</code></td>
      <td></td>
      <td>include files</td>
    </tr>
    <tr>
      <td><a HREF="../tst"><code>tst</code></a></td>
      <td></td>
      <td>test suite</td>
    </tr>
    <tr>
      <td><code><a HREF="../alpha">alpha</a>/*/tst</code></td>
      <td></td>
      <td>ALPHA test outputs</td>
    </tr>
    <tr>
      <td><code><a HREF="../mips">mips</a>/*/tst</code></td>
      <td></td>
      <td>MIPS test outputs</td>
    </tr>
    <tr>
      <td><code><a HREF="../sparc">sparc</a>/*/tst</code></td>
      <td></td>
      <td>SPARC test outputs</td>
    </tr>
    <tr>
      <td><code><a HREF="../x86">x86</a>/*/tst</code></td>
      <td></td>
      <td>X86 test outputs</td>
    </tr>
  </table>
</blockquote>

<p><code>doc/install.html</code> is the HTML file for this document.</p>

<p>The installation makefile is designed so that lcc can be installed from a read-only
file system or directory, which is common in networked environments, so the distribution
can be unloaded on a central file server. <strong>You will need an existing ANSI/ISO C
compiler to build and install lcc.</strong></p>

<h2><a NAME="unix">Installation on UNIX</a></h2>

<p>The compilation components (the preprocessor, include files, and compiler proper, etc.)
are installed in a single <em>build directory</em>. On multi-platform systems supported by
a central file server, it's common to store the build directory in a location specific to
the platform and to the version of lcc, and to point a symbolic link to this location. For
example,</p>

<blockquote>
  <pre>% ln -s /proj/pkg/lcc/4.2/sparc-solaris /usr/local/lib/lcc</pre>
</blockquote>

<p>points <code>/usr/local/lib/lcc</code> to a build directory for lcc on the SPARC under Solaris. Links into <code>/usr/local/lib/lcc</code> are created for the programs <code>lcc</code>
and <code>bprint</code>. Thus, a new distribution can be installed by building it in its
own build directory and changing one symbolic link to point to that directory. If these
conventions or their equivalents are followed, the host-specific parts of the driver
program, <code>lcc</code>, can be used unmodified.</p>

<p>Installation on a UNIX system involves the following steps. Below, the build directory
is referred to as <code>BUILDDIR</code>, and the commands below are executed 
from the distribution directory.<ol>
  <li>Create the build directory, using a version- and platform-specific naming convention as
    suggested above, and record the name of this directory in the <code>BUILDDIR</code>
    environment variable:<blockquote>
      <pre>% setenv BUILDDIR /proj/pkg/lcc/4.2/sparc-solaris
% mkdir -p $BUILDDIR</pre>
    </blockquote>
    <p>Here and below, commands assume the C shell. Also, you'll need a version of <code>mkdir</code>
    that supports the <code>-p</code> option, which creates intermediate directories as
    necessary.</p>
  </li>
  <li>Copy the man pages to the repository for local man pages, e.g.,<blockquote>
      <pre>% cp doc/*.1 /usr/local/man/man1</pre>
    </blockquote>
    <p>Some users copy the man pages to the build directory and create the appropriate
    symbolic links, e.g., </p>
    <blockquote>
      <pre>% cp doc/*.1 $BUILDDIR
% ln -s $BUILDDIR/*.1 /usr/local/man/man1</pre>
    </blockquote>
  </li>
  <li>Platform-specific include files are in directories named <code>include/</code><em>target</em><code>/</code><em>os</em>.
    Create the include directory in the build directory, and copy the include hierarchy for
    your platform to this directory, e.g.,<blockquote>
      <pre>% mkdir $BUILDDIR/include
% cp -p -R include/sparc/solaris/* $BUILDDIR/include</pre>
    </blockquote>
    <p>Again, some users create a symbolic link to the appropriate directory in the
    distribution instead of copying the include files. For example, at Princeton, the
    distributions are stored under <code>/proj/pkg/lcc</code>, so the included files are
    &quot;installed&quot; by creating one symbolic link: </p>
    <blockquote>
      <pre>% ln -s /proj/pkg/lcc/4.2/include/sparc/solaris $BUILDDIR/include</pre>
    </blockquote>
    <p>If you're installing lcc on Linux, you <em>must</em> also plant a symbolic link named <code>gcc</code>
    to gcc's library directory, because lcc uses gcc's C preprocessor and most of gcc's header
    files:</p>
    <blockquote>
      <pre>% ln -s /usr/lib/gcc-lib/i386-redhat-linux/2.96 $BUILDDIR/gcc</pre>
    </blockquote>
    <p>The library directory shown above may be different on your Linux machine; to determine
    the correct directory, browse <code>/usr/lib/gcc-lib</code>, or execute</p>
    <blockquote>
      <pre>% cc -v tst/8q.c</pre>
    </blockquote>
    <p>and examine the diagnostic output. Make sure that <code>$BUILDDIR/gcc/cpp0</code> and <code>$BUILDDIR/gcc/include</code> 
    are, respectively, gcc's C preprocessor and header files. On Linux, lcc looks for
    include files in <code>$BUILDDIR/include</code>, <code>$BUILDDIR/gcc/include</code>, and <code>/usr/include</code>,
    in that order; see <a HREF="#driver"><em>Building the Driver</em></a> and <a
    href="../etc/linux.c"><code>etc/linux.c</code></a> for details.</p>
  </li>
  <li>The <a HREF="../makefile"><code>makefile</code></a> includes the file named by the <code>CUSTOM</code>
    macro; the default is <code>custom.mk</code>, and an empty <code>custom.mk</code> is
    included in the distribution. If desired, prepare a site-specification customization file
    and define <code>CUSTOM</code> to the path of that file when invoking make in steps 5 and
    6, e.g.,<blockquote>
      <pre>make CUSTOM=<a href="http://www.cs.princeton.edu/software/lcc/pkg/solaris.mk">solaris.mk</a></pre>
    </blockquote>
    <p>You can, for example, use customization files to record site-specific values for macros
    instead of using environment variables, and to record targets for the steps in this list.</p>
  </li>
  <li>Build the host-specific driver, creating a custom host-specific part, if necessary. See <a
    HREF="#driver"><em>Building the Driver</em></a>.</li>
  <li>Build the preprocessor, compiler proper, library, and other accessories. See <a
    HREF="#rcc"><em>Building the Compiler</em></a>.</li>
  <li>Plant symbolic links to the build directory and to the installed programs, e.g.,<blockquote>
      <pre>% ln -s $BUILDDIR /usr/local/lib/lcc
% ln -s /usr/local/lib/{lcc,bprint} /usr/local/bin</pre>
    </blockquote>
    <p>Some users copy <code>bprint</code> and <code>lcc</code> into <code>/usr/local/bin</code>
    instead of creating symbolic links. The advantage of creating the links for <code>lcc</code>
    and <code>bprint</code> as shown is that, once established, they point indirectly to
    whatever <code>/usr/local/lib/lcc</code> points to; installing a new version of lcc can be done by changing <code>/usr/local/lib/lcc</code> to point to the build
    directory for the new version.</p>
  </li>
</ol>

<h2><a NAME="driver">Building the Driver</a></h2>

<p>The preprocessor, compiler, assembler, and loader are invoked by a driver program, <code>lcc</code>,
which is similar to <code>cc</code> on most systems. It's described in the man page <code>doc/lcc.1</code>.
The driver is built by combining the host-independent part, <a href="../etc/lcc.c"><code>etc/lcc.c</code></a>,
with a small host-specific part. Distributed host-specific parts are named <code>etc/</code><em>os</em><code>.c</code>,
where <em>os</em> is the name of the operating system for the host on which <code>lcc</code>
is being installed. If you're following the installations conventions described above, you
can probably use one of the host-specific parts unmodified; otherwise, pick one that is
closely related to your platform, copy it to <em>whatever</em><code>.c</code>, and edit it
as described below. You should not have to edit <code>etc/lcc.c</code>.</p>

<p>We'll use <a HREF="../etc/solaris.c"><code>etc/solaris.c</code></a> as an example in
describing how the host-specific part works. This example illustrates all the important
features. Make sure you have the environment variable <code>BUILDDIR</code> set correctly,
and build the driver with a <code>make</code> command, e.g.,</p>

<blockquote>
  <pre>% make HOSTFILE=etc/solaris.c lcc
cc -g -c -o $BUILDDIR/lcc.o etc/lcc.c
cc -g -c -o $BUILDDIR/host.o etc/solaris.c
cc -g -o $BUILDDIR/lcc $BUILDDIR/lcc.o $BUILDDIR/host.o</pre>
</blockquote>

<p>Of course, the actual value of <code>BUILDDIR</code> will appear in place of
<code>$BUILDDIR</code>. The symbolic name <code>HOSTFILE</code> specifies the path to the host-specific part,
either one in the distribution or <em>whatever</em><code>.c</code>. Some versions of make
may require the <code>-e</code> option in order to read the environment.</p>

<p>Here's <code>etc/solaris.c</code>:</p>

<blockquote>
  <pre>/* Sparcs running Solaris 2.5.1 at CS Dept., Princeton University */

#include &lt;string.h&gt;

static char rcsid[] = &quot;$ Id: solaris.c,v 1.10 1998/09/14 20:36:33 drh Exp $&quot;;

#ifndef LCCDIR
#define LCCDIR &quot;/usr/local/lib/lcc/&quot;
#endif
#ifndef SUNDIR
#define SUNDIR &quot;/opt/SUNWspro/SC4.2/lib/&quot;
#endif

char *suffixes[] = { &quot;.c&quot;, &quot;.i&quot;, &quot;.s&quot;, &quot;.o&quot;, &quot;.out&quot;, 0 };
char inputs[256] = &quot;&quot;;
char *cpp[] = { LCCDIR &quot;cpp&quot;,
	&quot;-D__STDC__=1&quot;, &quot;-Dsparc&quot;, &quot;-D__sparc__&quot;, &quot;-Dsun&quot;, &quot;-D__sun__&quot;, &quot;-Dunix&quot;,
	&quot;$1&quot;, &quot;$2&quot;, &quot;$3&quot;, 0 };
char *include[] = { &quot;-I&quot; LCCDIR &quot;include&quot;, &quot;-I/usr/local/include&quot;,
	&quot;-I/usr/include&quot;, 0 };
char *com[] = { LCCDIR &quot;rcc&quot;, &quot;-target=sparc/solaris&quot;,
	&quot;$1&quot;, &quot;$2&quot;, &quot;$3&quot;, 0 };
char *as[] = { &quot;/usr/ccs/bin/as&quot;, &quot;-Qy&quot;, &quot;-s&quot;, &quot;-o&quot;, &quot;$3&quot;, &quot;$1&quot;, &quot;$2&quot;, 0 };
char *ld[] = { &quot;/usr/ccs/bin/ld&quot;, &quot;-o&quot;, &quot;$3&quot;, &quot;$1&quot;,
	SUNDIR &quot;crti.o&quot;, SUNDIR &quot;crt1.o&quot;,
	SUNDIR &quot;values-xa.o&quot;, &quot;$2&quot;, &quot;&quot;,
	&quot;-Y&quot;, &quot;P,&quot; SUNDIR &quot;:/usr/ccs/lib:/usr/lib&quot;, &quot;-Qy&quot;,
	&quot;-L&quot; LCCDIR, &quot;-llcc&quot;, &quot;-lm&quot;, &quot;-lc&quot;, SUNDIR &quot;crtn.o&quot;, 0 };

extern char *concat(char *, char *);

int option(char *arg) {
	if (strncmp(arg, &quot;-lccdir=&quot;, 8) == 0) {
		cpp[0] = concat(&amp;arg[8], &quot;/cpp&quot;);
		include[0] = concat(&quot;-I&quot;, concat(&amp;arg[8], &quot;/include&quot;));
		ld[12] = concat(&quot;-L&quot;, &amp;arg[8]);
		com[0] = concat(&amp;arg[8], &quot;/rcc&quot;);
	} else if (strcmp(arg, &quot;-p&quot;) == 0) {
		ld[5] = SUNDIR &quot;mcrt1.o&quot;;
		ld[10] = &quot;P,&quot; SUNDIR &quot;libp:/usr/ccs/lib/libp:/usr/lib/libp:&quot;
			 SUNDIR &quot;:/usr/ccs/lib:/usr/lib&quot;;
	} else if (strcmp(arg, &quot;-b&quot;) == 0)
		;
	else if (strncmp(arg, &quot;-ld=&quot;, 4) == 0)
		ld[0] = &amp;arg[4];
	else
		return 0;
	return 1;
}</pre>
</blockquote>

<p><code>LCCDIR</code> defaults to <code>&quot;/usr/local/lib/lcc/&quot;</code> unless
it's defined by a <code>-D</code> option as part of <code>CFLAGS</code> in the make
command, e.g.,</p>

<blockquote>
  <pre>% make HOSTFILE=etc/solaris.c CFLAGS='-DLCCDIR=\&quot;/v/lib/lcc/\&quot;' lcc</pre>
</blockquote>

<p>Note the trailing slash; <code>SUNDIR</code> is provided so you can use <code>etc/solaris.c</code>
even if you have a different version of the Sun Pro compiler suite. If you're using the
gcc compiler tools instead of the Sun Pro tools, see <a HREF="../etc/gcc-solaris.c"><code>etc/gcc-solaris.c</code></a>.</p>

<p>Most of the host-specific code is platform-specific data and templates for the commands
that invoke the preprocessor, compiler, assembler, and loader. The <code>suffixes</code>
array lists the file name suffixes for C source files, preprocessed source files, assembly
language source files, object files, and executable files. <code>suffixes</code> must be
terminated with a null pointer, as shown above. The initialization of <code>suffixes</code>
in <code><a HREF="../etc/solaris.c">etc/solaris.c</a></code> are the typical ones for UNIX
systems. Each element of <code>suffixes</code> is actually a list of suffixes, separated
by semicolons; <code><a HREF="../etc/win32.c">etc/win32.c</a></code> holds an example:</p>

<blockquote>
  <pre>char *suffixes[] = { &quot;.c;.C&quot;, &quot;.i;.I&quot;, &quot;.asm;.ASM;.s;.S&quot;, &quot;.obj;.OBJ&quot;, &quot;.exe&quot;, 0 };</pre>
</blockquote>

<p>When a list is given, the first suffix is used whenever lcc needs to generate a file
name. For example, with <code><a HREF="../etc/win32.c">etc/win32.c</a></code>, lcc emits
the generated assembly code into <code>.asm</code> files.</p>

<p>The <code>inputs</code> array holds a null-terminated string of directories separated
by colons or semicolons. These are used as the default value of <code>LCCINPUTS</code>, if
the environment variable <code>LCCINPUTS</code> is not set; see the <a HREF="lcc.pdf">man
page</a>.</p>

<p>Each command template is an array of pointers to strings terminated with a null
pointer; the strings are full path names of commands, arguments, or argument placeholders,
which are described below. Commands are executed in a child process, and templates can
contain multiple commands by separating commands with newlines. The driver runs each
command in a new process.</p>

<p>The <code>cpp</code> array gives the command for running lcc's preprocessor, <code>cpp</code>.
Literal arguments specified in templates, e.g., <code>&quot;-Dsparc&quot;</code> in the <code>cpp</code>
command above, are passed to the command as given.</p>

<p>The strings <code>&quot;$1&quot;</code>, <code>&quot;$2&quot;</code>, and <code>&quot;$3&quot;</code>
in templates are placeholders for <em>lists</em> of arguments that are substituted in a
copy of the template before the command is executed. <code>$1</code> is replaced by the <em>options</em>
specified by the user; for the preprocessor, this list always contains at least <code>-D__LCC__</code>.
<code>$2</code> is replaced by the <em>input</em> files, and <code>$3</code> is replaced
by the <em>output</em> file.</p>

<p>Zero-length arguments after replacement are removed from the argument list before the
command is invoked. So, for example, if the preprocessor is invoked without an output
file, <code>&quot;$3&quot;</code> becomes <code>&quot;&quot;</code>, which is removed from
the final argument list.</p>

<p>The <code>include</code> array is a list of <code>-I</code> options that specify which
directives should be searched to satisfy include directives. These directories are
searched in the order given. The first directory should be the one to which the ANSI
header files were copied as described in <a HREF="#unix">UNIX</a> or <a HREF="#win32">Windows</a>
installation instructions. The driver adds these options to <code>cpp</code>'s arguments
when it invokes the preprocessor, except when <code>-N</code> is specified.</p>

<p><code>com</code> gives the command for invoking the compiler. This template can appear
as shown above in a custom host-specific part, but the option <code>-target=sparc/solaris</code>
should be edited to the <em>target</em><code>/</code><em>os</em> for your platform. If <code>com[1]</code>
includes the string &quot;<code>win32</code>&quot;, the driver assumes it's running on
Windows. lcc can generate code for <em>all</em> of the <em>target</em><code>/</code><em>os</em>
combinations listed in the file <code>src/bind.c</code>. The <code>-target</code> option
specifies the default combination. The driver's <code>-Wf</code> option can be used to
specify other combinations; the <a HREF="lcc.pdf">man page</a> elaborates.</p>

<p><code>as</code> gives the command for invoking the assembler. On Linux, you must be
running at least version 2.8.1 of the GNU assembler; earlier versions mis-assemble some
instructions emitted by lcc.</p>

<p><code>ld</code> gives the command for invoking the loader. For the other commands, the
list <code>$2</code> contains a single file; for <code>ld</code>, <code>$2</code> contains
all &quot;.o&quot; files and libraries, and <code>$3</code> is <code>a.out</code>, unless
the <code>-o</code> option is specified. As suggested in the code above, <code>ld</code>
must also specify the appropriate startup code and default libraries, including the lcc
library, <code>liblcc.a</code>.</p>

<p>The <code>option</code> function is described below; the minimal <code>option</code>
function just returns 0.</p>

<p>You can test <code>lcc</code> with the options <code>-v -v</code> to display the
commands that would be executed, e.g.,</p>

<blockquote>
  <pre>% $BUILDDIR/lcc -v -v foo.c baz.c mylib.a -lX11
$BUILDDIR/lcc $ Id: lcc.c,v 4.33 2001/06/28 22:19:58 drh $
foo.c:
/usr/local/lib/lcc/cpp -D__STDC__=1 -Dsparc -D__sparc__ -Dsun -D__sun__ -Dunix -D__LCC__i
/usr/local/lib/lcc/rcc -target=sparc/solaris -v /tmp/lcc4060.i /tmp/lcc4061.s
/usr/ccs/bin/as -Qy -s -o /tmp/lcc4062.o /tmp/lcc4061.s
baz.c:
/usr/local/lib/lcc/cpp -D__STDC__=1 -Dsparc -D__sparc__ -Dsun -D__sun__ -Dunix -D__LCC__i
/usr/local/lib/lcc/rcc -target=sparc/solaris -v /tmp/lcc4060.i /tmp/lcc4061.s
/usr/ccs/bin/as -Qy -s -o /tmp/lcc4063.o /tmp/lcc4061.s
/usr/ccs/bin/ld -o a.out /opt/SUNWspro/SC4.2/lib/crti.o /opt/SUNWspro/SC4.2/lib/crt1.o /o
rm /tmp/lcc4063.o /tmp/lcc4060.i /tmp/lcc4061.s /tmp/lcc4062.o</pre>
</blockquote>

<p>As the output shows, <code>lcc</code> places temporary files in <code>/tmp</code>; if
any of the environment variables <code>TMP</code>, <code>TEMP</code>, and <code>TMPDIR</code>
are set, they override this default (in the order shown) as does the <code>-tempdir=</code><em>dir</em>
option. The default can be changed by defining <code>TEMPDIR</code> in <code>CFLAGS</code>
when building the driver.</p>

<p>The <code>option</code> function is called for the options <code>-Wo</code>, <code>-g</code>,
<code>-p</code>, <code>-pg</code>, and <code>-b</code> because these compiler options
might also affect the loader's arguments. For these options, the driver calls <code>option(arg)</code>
to give the host-specific code an opportunity to edit the <code>ld</code> command, if
necessary. <code>option</code> can change <code>ld</code>, if necessary, and return 1 to
announce its acceptance of the option. If the option is unsupported, <code>option</code>
should return 0.</p>

<p>For example, in response to <code>-g</code>, the <code>option</code> function shown
above accepts the option but does nothing else, because the <code>ld</code> and <code>as</code>
commands don't need to be modified on the SPARC. <code>-g</code> will also be added to the
compiler's options by the host-independent part of the driver. The <code>-p</code> causes <code>option</code>
to change the name of the startup code and changed the list of libraries. The <code>-b</code>
option turns on <code>lcc</code>'s per-expression profiling, the code for which is in <code>liblcc.a</code>,
so <code>option</code> need no nothing.</p>

<p>On SPARCs, the driver also recognizes <code>-Bstatic</code> and <code>-Bdynamic</code>
as linker options. The driver recognizes but ignores &quot;<code>-target</code> <em>name</em>&quot;
option.</p>

<p>The option <code>-Wo</code><em>arg</em> causes the driver to pass <em>arg</em> to <code>option</code>.
Such options have no other effect; this mechanism is provided to support system-specific
options that affect the commands executed by the driver. As illustrated above,
host-specific parts should support the <code>-Wo-lccdir=</code><em>dir</em> option, which
causes lcc's compilation components to be found in <em>dir</em>, because this option is
used by the test scripts, and because the driver simulates a <code>-Wo-lccdir</code>
option with the value of the environment variable <code>LCCDIR</code>, if it's defined.
The code above rebuilds the paths to the include files, preprocessor, compiler, and
library by calling <code>concat</code>, which is defined in <code>etc/lcc.c</code>.</p>

<h2><a NAME="rcc">Building the Compiler and Accessories</a></h2>

<p>To build the rest of compilation components make sure <code>BUILDDIR</code> is set
appropriately and type &quot;<code>make all</code>&quot;. This command builds <code>librcc.a</code>
(the compiler's private library), <code>rcc</code> (the compiler proper), <code>lburg</code>
(the code-generator generator), <code>cpp</code> (the preprocessor), <code>liblcc.a</code>
(the runtime library), and <code>bprint</code> (the profile printer), all in <code>BUILDDIR</code>.
There may be warnings, but there should be no errors. If you're using an ANSI/ISO compiler
other than <code>cc</code>, specify its name with the <code>CC=</code> option, e.g.,
&quot;<code>make CC=gcc all</code>&quot;. If you're running on a DEC ALPHA, use &quot;<code>make
CC='cc -std1' all</code>&quot;; the <code>-std1</code> option is essential on 
the ALPHA.</p>

<p>Once <code>rcc</code> is built with the host C compiler, run the test suite to verify
that <code>rcc</code> is working correctly. If any of the steps below fail, contact us
(see <a HREF="#bugs"><em>Reporting Bugs</em></a>). The commands in the makefile run the
shell script <code>src/run.sh</code> on each C program in the test suite, <code>tst/*.c</code>.
It uses the driver, <code>$BUILDDIR/lcc</code>, so you must have the driver in the build
directory before testing <code>rcc</code>. The <em>target</em><code>/</code><em>os</em>
combination is read from the variable <code>TARGET</code>, which must be specified when
invoking <code>make</code>:</p>

<blockquote>
  <pre>% make TARGET=sparc/solaris test
mkdir -p $BUILDDIR/sparc/solaris/tst
$BUILDDIR/rcc -target=sparc/solaris $BUILDDIR/sparc/solaris/tst/8q.s:
$BUILDDIR/rcc -target=sparc/solaris $BUILDDIR/sparc/solaris/tst/array.s:
$BUILDDIR/rcc -target=sparc/solaris $BUILDDIR/sparc/solaris/tst/cf.s:
$BUILDDIR/rcc -target=sparc/solaris $BUILDDIR/sparc/solaris/tst/cq.s:
$BUILDDIR/rcc -target=sparc/solaris $BUILDDIR/sparc/solaris/tst/cvt.s:
$BUILDDIR/rcc -target=sparc/solaris $BUILDDIR/sparc/solaris/tst/fields.s:
$BUILDDIR/rcc -target=sparc/solaris $BUILDDIR/sparc/solaris/tst/front.s:
$BUILDDIR/rcc -target=sparc/solaris $BUILDDIR/sparc/solaris/tst/incr.s:
$BUILDDIR/rcc -target=sparc/solaris $BUILDDIR/sparc/solaris/tst/init.s:
$BUILDDIR/rcc -target=sparc/solaris $BUILDDIR/sparc/solaris/tst/limits.s:
$BUILDDIR/rcc -target=sparc/solaris $BUILDDIR/sparc/solaris/tst/paranoia.s:
$BUILDDIR/rcc -target=sparc/solaris $BUILDDIR/sparc/solaris/tst/sort.s:
$BUILDDIR/rcc -target=sparc/solaris $BUILDDIR/sparc/solaris/tst/spill.s:
$BUILDDIR/rcc -target=sparc/solaris $BUILDDIR/sparc/solaris/tst/stdarg.s:
$BUILDDIR/rcc -target=sparc/solaris $BUILDDIR/sparc/solaris/tst/struct.s:
$BUILDDIR/rcc -target=sparc/solaris $BUILDDIR/sparc/solaris/tst/switch.s:
$BUILDDIR/rcc -target=sparc/solaris $BUILDDIR/sparc/solaris/tst/wf1.s:
$BUILDDIR/rcc -target=sparc/solaris $BUILDDIR/sparc/solaris/tst/yacc.s:</pre>
</blockquote>

<p>Each line in the output above is of the form</p>

<blockquote>
  <p><code>$BUILDDIR/rcc -target=</code><em>target</em><code>/</code><em>os</em><code> $BUILDDIR/</code><em>target</em><code>/</code><em>os</em><code>/</code><em>X</em><code>.s:</code></p>
</blockquote>

<p>where <em>X</em> is the base name of the C program <em>X</em><code>.c</code> in the
test suite. The actual value of <code>BUILDDIR</code> will, of course, appear in 
place of <code>$BUILDDIR</code>. This output identifies the compiler and the target, e.g., &quot;<code>$BUILDDIR/rcc</code>
is generating code for a <code>sparc</code> running the <code>solaris</code> operating
system.&quot;</p>

<p>For each program in the test suite, <code>src/run.sh</code> compiles the program, drops
the generated assembly language code in <code>BUILDDIR</code>/<em>target</em><code>/</code><em>os</em>,
and uses <code>diff</code> to compare the generated assembly code with the expected code
(the code expected for <code>tst/8q.c</code> on the SPARC under Solaris is in <code>sparc/solaris/tst/8q.sbk</code>,
etc.). If there are differences, the script executes the generated code with the input
given in <code>tst</code> (the input for <code>tst/8q.c</code> is in <code>tst/8q.0</code>,
etc.) and compares the output with the expected output (the expected output from <code>tst/8q.c</code>
on the SPARC under Solaris is in <code>sparc/solaris/tst/8q.1bk</code>, etc.). The script
also compares the diagnostics from the compiler with the expected diagnostics.</p>

<p>On some systems, there may be a few differences between the generated code and the
expected code. These differences occur because the expected code is generated by cross
compilation and the least significant bits of some floating-point constants differ from
those bits in constants generated on your system. On Linux, there may be differences
because of differences in the header files between our system and yours. There should be
no differences in the output from executing the test programs.</p>

<p>Next, run the &quot;triple test&quot;, which builds <code>rcc</code> using itself:</p>

<blockquote>
  <pre>% make triple
$BUILDDIR/lcc -A -d0.6 -Wo-lccdir=$(BUILDDIR) -Isrc -I$(BUILDDIR) -o $BUILDDIR/1rcc -B$BUILDDIR/ src/alloc.c ...
src/alloc.c:
...
$BUILDDIR/lcc -A -d0.6 -Wo-lccdir=$(BUILDDIR) -Isrc -I$(BUILDDIR) -o $BUILDDIR/2rcc -B$BUILDDIR/1 src/alloc.c ...
src/alloc.c:
...
strip $BUILDDIR/[12]rcc
dd if=$BUILDDIR/1rcc of=$BUILDDIR/rcc1 bs=512 skip=1
1270+1 records in
1270+1 records out
dd if=$BUILDDIR/2rcc of=$BUILDDIR/rcc2 bs=512 skip=1
1270+1 records in
1270+1 records out
if cmp $BUILDDIR/rcc[12]; then \
        mv $BUILDDIR/2rcc $BUILDDIR/rcc; \
        rm -f $BUILDDIR/1rcc $BUILDDIR/rcc[12]; fi</pre>
</blockquote>

<p>This command builds <code>rcc</code> twice; once using the <code>rcc</code> built by <code>cc</code>
and again using the <code>rcc</code> built by <code>lcc</code>. The resulting binaries are
compared. They should be identical, as shown at the end of the output above. If they
aren't, our compiler is generating incorrect code; <a HREF="#bugs">contact</a> us.</p>

<p>The final version of <code>rcc</code> should also pass the test suite; that is, the
output from</p>

<blockquote>
  <pre>% make TARGET=sparc/solaris test</pre>
</blockquote>

<p>should be identical to that from the previous <code>make test</code>.</p>

<p>The command &quot;<code>make clean</code>&quot; cleans up, but does not remove <code>rcc</code>,
etc., and &quot;<code>make clobber</code>&quot; cleans up and removes <code>lcc</code>, <code>rcc</code>,
and the other accessories. Test directories under <code>BUILDDIR</code> are <em>not</em>
removed; you'll need to remove these by hand, e.g.,</p>

<blockquote>
  <pre>% rm -fr $BUILDDIR/sparc</pre>
</blockquote>

<p>The code generators for the other targets can be tested by specifying the desired <em>target</em><code>/</code><em>os</em>
and setting an environment variable that controls what <code>src/run.sh</code> does. For
example, to test the MIPS code generator, type</p>

<blockquote>
  <pre>% setenv REMOTEHOST noexecute
% make TARGET=mips/irix test</pre>
</blockquote>

<p>As above, <code>src/run.sh</code> compares the MIPS code generated with what's
expected. There should be no differences. Setting <code>REMOTEHOST</code> to <code>noexecute</code>
suppresses the assembly and execution of the generated code. If you set <code>REMOTEHOST</code>
to the name of a MIPS machine to which you can <code>rlogin</code>, <code>src/run.sh</code>
will <code>rcp</code> the generated code to that machine and execute it there, if
necessary. See <code>src/run.sh</code> for the details.</p>

<p>You can use lcc as a cross compiler. The options <code>-S</code> and <code>-Wf-target=</code><em>target/os</em>
generate assembly code for the specified target, which is any of those listed in the file <code>src/bind.c</code>.
For example, </p>

<blockquote>
  <pre>% lcc -Wf-target=mips/irix -S tst/8q.c</pre>
</blockquote>

<p>generates MIPS code for <code>tst/8q.c</code> in <code>8q.s</code>.</p>

<p>lcc can also generate code for a &quot;symbolic&quot; target. This target is used
routinely in front-end development, and its output is a printable representation of the
input program, e.g., the dags constructed by the front end are printed, and other
interface functions print their arguments. You can specify this target with the option <code>-Wf-target=symbolic</code>.
For example,</p>

<blockquote>
  <pre>% lcc -Wf-target=symbolic -S tst/8q.c</pre>
</blockquote>

<p>generates symbolic output for <code>tst/8q.c</code> in <code>8q.s</code>. Adding <code>-Wf-html</code>
causes the symbolic target to emit HTML instead of plain text. Finally, the option <code>-Wf-target=null</code>
specifies the &quot;null&quot; target for which lcc emits nothing and thus only checks the
syntax and semantics of its input files.</p>

<h2><a NAME="win32">Installation on Windows</a></h2>

<p>On Windows, lcc is designed to work with Microsoft's Visual
C++ (VC), version 5.0 and above, and Microsoft's Assembler, MASM. It uses the VC header files,
libraries, and command-line tools, and it uses MASM to assemble the code it generates. 
You must use MASM 6.11d or later,
because earlier  releases generate incorrect COFF object files. MASM 
6.15 is available as part of the free
<a href="http://msdn.microsoft.com/vstudio/downloads/ppack/default.asp">Visual 
C++ 6.0 Processor Pack</a>.</p>

<p>Building the distribution components from the ground up requires Microsoft's Visual
C/C++ compiler, Microsoft's make, <code>nmake</code>, and the standard Windows command
interpreter. <a HREF="../makefile.nt"><code>makefile.nt</code></a> is written to use only <code>nmake</code>.
As on UNIX systems, the compilation components are installed in a single <em>build
directory</em>, and the top-level programs, <code>lcc.exe</code> and <code>bprint.exe</code>,
are installed in a directory on the PATH. If the conventions used below are followed, the
Windows-specific parts of the driver program, <code>lcc.exe</code>, can be used
unmodified.</p>

<p>Building from the source distribution on a Windows system involves the following steps.
Below, the build directory is referred to as <code>BUILDDIR</code>, and the distribution
is in <code>\dist\lcc</code>. 

<ol>
  <li>Create the build directory, perhaps using a version- and platform-specific naming
    convention as suggested in <a HREF="#unix"><em>Installation on UNIX</em></a>, and record
    the name of this directory in the <code>BUILDDIR</code> environment variable:<blockquote>
      <pre>C:\dist\lcc&gt;set BUILDDIR=\progra~1\lcc\<i>version</i>\bin
C:\dist\lcc&gt;mkdir %BUILDDIR%</pre>
    </blockquote>
    <p>The default build, or installation, directory is <code>\Program Files\lcc\</code><i>version</i><code>\bin</code>, 
    where <i>version</i> is the version number, e.g., 4.2, but the <code>nmake</code> commands require that you use the corresponding 8.3 file name, <code>progra~1</code>,
    instead of <code>Program Files</code>.</p>
  </li>
  <li><a HREF="../etc/win32.c"><code>etc\win32.c</code></a> is the Windows-specific part of
    the driver. It assumes that environment variable <code>include</code> gives the locations
    of the VC header files and that the linker (<code>link.exe</code>) and the assembler (<code>ml.exe</code>)
    are on the PATH. It also assumes that the macro <code>LCCDIR</code> gives the build
    directory. If necessary, revise a copy of <a HREF="../etc/win32.c"><code>etc\win32.c</code></a>
    to reflect the conventions on your computer (see <a HREF="#driver"><em>Building the Driver</em></a>),
    then build the driver, specifying the default temporary directory, if necessary:<blockquote>
      <pre>C:\dist\lcc&gt;nmake -f makefile.nt HOSTFILE=etc/win32.c lcc
...
        cl -nologo -Zi -MLd -Fd%BUILDDIR%\ -c -Fo%BUILDDIR%\lcc.obj etc/lcc.c
lcc.c
        cl -nologo -Zi -MLd -Fd%BUILDDIR%\ -c -Fo%BUILDDIR%\host.obj etc/win32.c
win32.c
        cl -nologo -Zi -MLd -Fd%BUILDDIR%\ -Fe%BUILDDIR%\lcc.exe %BUILDDIR%\lcc.obj %BUILDDIR%\host.obj</pre>
    </blockquote>
    <p>If you make a copy of <code>etc\win32.c</code>, specify the path of the copy as the
    value of <code>HOSTFILE</code>. For example, if you copy <code>etc\win32.c</code> to <code>BUILDDIR</code>
    and edit it, use the command</p>
    <blockquote>
      <pre>C:\dist\lcc&gt;nmake -f makefile.nt HOSTFILE=%BUILDDIR%\win32.c lcc</pre>
    </blockquote>
  </li>
  <li>Build the preprocessor, compiler proper, library, and other accessories (see <a
    HREF="#rcc"><em>Building the Compiler</em></a>):<blockquote>
      <pre>C:\dist\lcc&gt;nmake -f makefile.nt all</pre>
    </blockquote>
    <p>This command uses the VC command-line tools <code>cl</code> and <code>lib</code> to
    build <code>bprint.exe</code>, <code>cpp.exe</code>, <code>lburg.exe</code>, <code>liblcc.lib</code>,
    <code>librcc.lib</code>, and <code>rcc.exe</code>, all in <code>BUILDDIR</code>. There may
    be some warnings, but there should be no warnings.</p>
  </li>
  <li>Create a test directory and run the test suite:<blockquote>
      <pre>C:\dist\lcc&gt;mkdir %BUILDDIR%\x86\win32\tst
C:\dist\lcc&gt;nmake -f makefile.nt test</pre>
    </blockquote>
    <p>This command compiles each program in <a HREF="../tst">tst</a>, compares the generated
    assembly code and diagnostics with the expected assembly code and diagnostics, executes
    the program, and compares the output with the expected output (using <code>fc</code>). For
    example, when the nmake command compiles <a HREF="../tst/8q.c"><code>tst\8q.c</code></a>,
    it leaves the generated assembly code and diagnostic output in <code>%BUILDDIR%\x86\win32\tst\8q.s</code>
    and <code>%BUILDDIR%\x86\win32\tst\8q.2</code>, and it compares them with the expected
    results in <code>x86\win32\tst\8q.sbk</code>. It builds the executable program in <code>%BUILDDIR%\x86\win32\tst\8q.exe</code>,
    runs it, and redirects the output to <code>%BUILDDIR%\x86\win32\tst\8q.1</code>, which it
    compares with <code>x86\win32\tst\8q.1bk</code>. The output from this step is voluminous,
    but there should be no differences and no errors.</p>
  </li>
  <li>Run the &quot;triple&quot; test, which compiles <code>rcc</code> with itself and
    verifies the results:<blockquote>
      <pre>C:\dist\lcc&gt;nmake -f makefile.nt triple
...
 Assembling: C:/TEMP/lcc2001.asm
        fc /b %BUILDDIR%\1rcc.exe %BUILDDIR%\2rcc.exe
Comparing files %BUILDDIR%\1rcc.exe and %BUILDDIR%\2RCC.EXE
00000088: B4 D5</pre>
    </blockquote>
    <p>This command builds <code>rcc</code> twice; once using the <code>rcc</code> built by VC
    and again using the <code>rcc</code> built by <code>lcc</code>. The resulting binaries are
    compared using <code>fc</code>. They should be identical, except for one or two bytes of
    timestamp data, as shown at the end of the output above (which will be 
    different on your system). If <code>1rcc.exe</code> and <code>2rcc.exe</code> aren't 
    identical, our compiler is
    generating incorrect code; <a HREF="#bugs">contact</a> us.</p>
  </li>
  <li>Copy <code>lcc.exe</code> and <code>bprint.exe</code> to a directory on your PATH, e.g.,<blockquote>
      <pre>C:\dist\lcc&gt;copy %BUILDDIR%\lcc.exe \bin
        1 file(s) copied.

C:\dist\lcc&gt;copy %BUILDDIR%\bprint.exe \bin
        1 file(s) copied.</pre>
    </blockquote>
  </li>
  <li>Finally, clean up:<blockquote>
      <pre>C:\dist\lcc&gt;nmake -f makefile.nt clean</pre>
    </blockquote>
    <p>This command removes the derived files in <code>BUILDDIR</code>, but does not remove <code>rcc.exe</code>,
    etc.; &quot;<code>nmake -f makefile.nt clobber</code>&quot; cleans up and removes all
    executables and libraries. Test directories under <code>BUILDDIR</code> are <em>not</em>
    removed; you'll need to remove these by hand, e.g.,</p>
    <blockquote>
      <pre>C:\dist\lcc&gt;rmdir %BUILDDIR%\x86 /s
%BUILDDIR%\x86, Are you sure (Y/N)? y</pre>
    </blockquote>
  </li>
</ol>

<h2><a NAME="bugs">Reporting Bugs</a></h2>

<p>lcc is a large, complex program. We find and repair errors routinely. If you think that
you've found a error, follow the steps below, which are adapted from the instructions in
Chapter 1 of <cite>A Retargetable C Compiler: Design and Implementation</cite>. 

<ol>
  <li>If you don't have a source file that displays the error, create one. Most errors are
    exposed when programmers try to compile a program they think is valid, so you probably
    have a demonstration program already.</li>
  <li>Preprocess the source file and capture the preprocessor output. Discard the original
    code.</li>
  <li>Prune your source code until it can be pruned no more without sending the error into
    hiding. We prune most error demonstrations to fewer than five lines.</li>
  <li>Confirm that the source file displays the error with the <em>distributed</em> version of
    lcc. If you've changed lcc and the error appears only in your version, then you'll have to
    chase the error yourself, even if it turns out to be our fault, because we can't work on
    your code.</li>
  <li>Annotate your code with comments that explain why you think that lcc is 
  wrong. If lcc dies with an assertion failure, please tell us where it died. If 
  lcc crashes, please report the last part of the call chain if you can. If lcc 
  is rejecting a program you think is valid, please tell us why you think it's 
  valid, and include supporting page numbers in the ANSI Standard or the
    appropriate section in <cite>C: A Reference Manual</cite>, 4th edition by S. B. Harbison
    and G. L. Steele, Jr. (Prentice Hall, 1995). If lcc silently generates incorrect code for
    some construct, please include the corrupt assembly code in the comments and flag the
    incorrect instructions if you can.</li>
  <li>Confirm that your error hasn't been fixed already. The latest version of lcc is always
    available for anonymous <code>ftp</code> from <code>ftp.cs.princeton.edu</code> in <a
    HREF="ftp://ftp.cs.princeton.edu/pub/lcc"><code>pub/lcc</code></a>. A <a
    HREF="ftp://ftp.cs.princeton.edu/pub/lcc/README"><code>README</code></a> file there gives
    acquisition details, and the <a HREF="../LOG"><code>LOG</code></a> file reports what errors
    were fixed and when they were fixed. If you report a error that's been fixed, you might
    get a canned reply.</li>
  <li>Post your program to the newsgroup <a href="news:comp.compilers.lcc"><code>comp.compilers.lcc</code></a> 
  using a USENET newsreader like those at <a href="http://www.dejanews.com/">http://www.dejanews.com/</a> 
  and <a href="http://groups.google.com/">http://groups.google.com/</a>.
    Please post only valid C programs; put all remarks in C comments so that we can process
    reports semi automatically.</li>
</ol>

<h2><a NAME="mailinglist">Keeping in Touch</a></h2>

<p>The USENET newsgroup <a href="news:comp.compilers.lcc">comp.compilers.lcc</a> is an
unmoderated newsgroup that serves as a forum for all topics related to the installation,
use, and development of lcc. You can post messages to comp.compilers.lcc using any USENET
newsreader or by visiting <a href="http://www.dejanews.com/">http://www.dejanews.com/</a>,
which also includes an archive of recent postings.</p>

<hr>

<address>
  <a HREF="http://cwfraser.webhop.net">Chris Fraser</a><br>
  <a HREF="http://drh.home.dyndns.org">David Hanson</a><br>
  $Revision: 355 $ $Date: 2007-02-18 14:08:49 -0800 (Sun, 18 Feb 2007) $ 
</address>
</body>
</html>