diff --git a/docs/FAQ.html b/docs/FAQ.html
new file mode 100644
index 0000000..a76fea6
--- /dev/null
+++ b/docs/FAQ.html
@@ -0,0 +1,145 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
+
+<h1>
+<center>
+LLVM: Frequently Asked Questions
+</center>
+</h1>
+
+<hr>
+
+<!--=====================================================================-->
+<h2>
+<a name="source">Source Code</a>
+</h2>
+<!--=====================================================================-->
+
+<dl compact>
+	<dt> <b>In what language is LLVM written?</b>
+	<dd>
+	All of the LLVM tools and libraries are written in C++ with extensive use
+	of the STL.
+	<p>
+
+	<dt><b>How portable is the LLVM source code?</b>
+	<dd>
+	The LLVM source code should be portable to most modern UNIX-like operating
+	systems.  Most of the code is written in standard C++ with operating
+	system services abstracted to a support library.  The tools required to
+	build and test LLVM have been ported to a plethora of platforms.
+	<p>
+	Some porting problems may exist in the following areas:
+	<ul>
+		<li>The GCC front end code is not as portable as the LLVM suite, so it
+		may not compile as well on unsupported platforms.
+
+		<p>
+
+		<li>The Python test classes are more UNIX-centric than they should be,
+		so porting to non-UNIX like platforms (i.e. Windows, MacOS 9) will
+		require some effort.
+		<p>
+
+		<li>The LLVM build system relies heavily on UNIX shell tools, like the
+		Bourne Shell and sed.  Porting to systems without these tools (MacOS 9,
+		Plan 9) will require more effort.
+	</ul>
+</dl>
+
+<hr>
+
+<!--=====================================================================-->
+<h2>
+<a name="build">Build Problems</a>
+</h2>
+<!--=====================================================================-->
+
+<dl compact>
+	<dt><b>When I run configure, it finds the wrong C compiler.</b>
+	<dd>
+	The <tt>configure</tt> script attempts to locate first <tt>gcc</tt> and
+	then <tt>cc</tt>, unless it finds compiler paths set in <tt>CC</tt> and
+	<tt>CXX</tt> for the C and C++ compiler, respectively.
+
+	If <tt>configure</tt> finds the wrong compiler, either adjust your
+	<tt>PATH</tt> environment variable or set <tt>CC</tt> and <tt>CXX</tt>
+	explicitly.
+	<p>
+
+	<dt><b>I compile the code, and I get some error about /localhome</b>.
+	<dd>
+	There are several possible causes for this.  The first is that you
+	didn't set a pathname properly when using <tt>configure</tt>, and it
+	defaulted to a pathname that we use on our research machines.
+	<p>
+	Another possibility is that we hardcoded a path in our Makefiles.  If
+	you see this, please email the LLVM bug mailing list with the name of
+	the offending Makefile and a description of what is wrong with it.
+
+	<dt><b>The <tt>configure</tt> script finds the right C compiler, but it
+	uses the LLVM linker from a previous build.  What do I do?</b>
+	<dd>
+	The <tt>configure</tt> script uses the <tt>PATH</tt> to find
+	executables, so if it's grabbing the wrong linker/assembler/etc, there
+	are two ways to fix it:
+	<ol>
+		<li>Adjust your <tt>PATH</tt> environment variable so that the
+		correct program appears first in the <tt>PATH</tt>.  This may work,
+		but may not be convenient when you want them <i>first</i> in your
+		path for other work.
+		<p>
+
+		<li>Run <tt>configure</tt> with an alternative <tt>PATH</tt> that
+		is correct.  In a Borne compatible shell, the syntax would be:
+		<p>
+		<tt>PATH=<the path without the bad program> ./configure ...</tt>
+		<p>
+		This is still somewhat inconvenient, but it allows
+		<tt>configure</tt> to do its work without having to adjust your
+		<tt>PATH</tt> permanently.
+	</ol>
+
+	<dt><b>When creating a dynamic library, I get a strange GLIBC error.</b>
+	<dd>
+	Under some operating systems (i.e. Linux), libtool does not work correctly
+	if GCC was compiled with the --disable-shared option.  To work around this,
+	install your own version of GCC that has shared libraries enabled by
+	default.
+	<p>
+
+	<dt><b>I've updated my source tree from CVS, and now my build is trying to
+	use a file/directory that doesn't exist.</b>
+	<dd>
+	You need to re-run configure in your object directory.  When new Makefiles
+	are added to the source tree, they have to be copied over to the object
+	tree in order to be used by the build.
+	<p>
+
+	<dt><b>I've modified a Makefile in my source tree, but my build tree keeps
+	using the old version.  What do I do?</b>
+	<dd>
+	If the Makefile already exists in your object tree, you can just run the
+	following command in the top level directory of your object tree:
+	<p>
+	<tt>./config.status &lt;relative path to Makefile&gt;</tt>
+	<p>
+	If the Makefile is new, you will have to modify the configure script to copy
+	it over.
+	<p>
+
+	<dt><b>I've upgraded to a new version of LLVM, and I get strange build
+	errors.</b>
+	<dd>
+	Sometimes changes to the LLVM source code alters how the build system
+	works.  Changes in libtool, autoconf, or header file dependencies are
+	especially prone to this sort of problem.
+	<p>
+	The best thing to try is to remove the old files and re-build.  In most
+	cases, this takes care of the problem.  To do this, just type <tt>make
+	clean</tt> and then <tt>make</tt> in the directory that fails to build.
+	<p>
+</dl>
+<hr>
+
+</body>
+</html>