diff options
| -rw-r--r-- | docs/FAQ.html | 145 |
1 files changed, 145 insertions, 0 deletions
diff --git a/docs/FAQ.html b/docs/FAQ.html new file mode 100644 index 0000000000..a76fea66f6 --- /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 <relative path to Makefile></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> |