John Criswell | c310f62 | 2003-10-13 16:13:06 +0000 | [diff] [blame^] | 1 | <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> |
| 2 | |
| 3 | <h1> |
| 4 | <center> |
| 5 | LLVM: Frequently Asked Questions |
| 6 | </center> |
| 7 | </h1> |
| 8 | |
| 9 | <hr> |
| 10 | |
| 11 | <!--=====================================================================--> |
| 12 | <h2> |
| 13 | <a name="source">Source Code</a> |
| 14 | </h2> |
| 15 | <!--=====================================================================--> |
| 16 | |
| 17 | <dl compact> |
| 18 | <dt> <b>In what language is LLVM written?</b> |
| 19 | <dd> |
| 20 | All of the LLVM tools and libraries are written in C++ with extensive use |
| 21 | of the STL. |
| 22 | <p> |
| 23 | |
| 24 | <dt><b>How portable is the LLVM source code?</b> |
| 25 | <dd> |
| 26 | The LLVM source code should be portable to most modern UNIX-like operating |
| 27 | systems. Most of the code is written in standard C++ with operating |
| 28 | system services abstracted to a support library. The tools required to |
| 29 | build and test LLVM have been ported to a plethora of platforms. |
| 30 | <p> |
| 31 | Some porting problems may exist in the following areas: |
| 32 | <ul> |
| 33 | <li>The GCC front end code is not as portable as the LLVM suite, so it |
| 34 | may not compile as well on unsupported platforms. |
| 35 | |
| 36 | <p> |
| 37 | |
| 38 | <li>The Python test classes are more UNIX-centric than they should be, |
| 39 | so porting to non-UNIX like platforms (i.e. Windows, MacOS 9) will |
| 40 | require some effort. |
| 41 | <p> |
| 42 | |
| 43 | <li>The LLVM build system relies heavily on UNIX shell tools, like the |
| 44 | Bourne Shell and sed. Porting to systems without these tools (MacOS 9, |
| 45 | Plan 9) will require more effort. |
| 46 | </ul> |
| 47 | </dl> |
| 48 | |
| 49 | <hr> |
| 50 | |
| 51 | <!--=====================================================================--> |
| 52 | <h2> |
| 53 | <a name="build">Build Problems</a> |
| 54 | </h2> |
| 55 | <!--=====================================================================--> |
| 56 | |
| 57 | <dl compact> |
| 58 | <dt><b>When I run configure, it finds the wrong C compiler.</b> |
| 59 | <dd> |
| 60 | The <tt>configure</tt> script attempts to locate first <tt>gcc</tt> and |
| 61 | then <tt>cc</tt>, unless it finds compiler paths set in <tt>CC</tt> and |
| 62 | <tt>CXX</tt> for the C and C++ compiler, respectively. |
| 63 | |
| 64 | If <tt>configure</tt> finds the wrong compiler, either adjust your |
| 65 | <tt>PATH</tt> environment variable or set <tt>CC</tt> and <tt>CXX</tt> |
| 66 | explicitly. |
| 67 | <p> |
| 68 | |
| 69 | <dt><b>I compile the code, and I get some error about /localhome</b>. |
| 70 | <dd> |
| 71 | There are several possible causes for this. The first is that you |
| 72 | didn't set a pathname properly when using <tt>configure</tt>, and it |
| 73 | defaulted to a pathname that we use on our research machines. |
| 74 | <p> |
| 75 | Another possibility is that we hardcoded a path in our Makefiles. If |
| 76 | you see this, please email the LLVM bug mailing list with the name of |
| 77 | the offending Makefile and a description of what is wrong with it. |
| 78 | |
| 79 | <dt><b>The <tt>configure</tt> script finds the right C compiler, but it |
| 80 | uses the LLVM linker from a previous build. What do I do?</b> |
| 81 | <dd> |
| 82 | The <tt>configure</tt> script uses the <tt>PATH</tt> to find |
| 83 | executables, so if it's grabbing the wrong linker/assembler/etc, there |
| 84 | are two ways to fix it: |
| 85 | <ol> |
| 86 | <li>Adjust your <tt>PATH</tt> environment variable so that the |
| 87 | correct program appears first in the <tt>PATH</tt>. This may work, |
| 88 | but may not be convenient when you want them <i>first</i> in your |
| 89 | path for other work. |
| 90 | <p> |
| 91 | |
| 92 | <li>Run <tt>configure</tt> with an alternative <tt>PATH</tt> that |
| 93 | is correct. In a Borne compatible shell, the syntax would be: |
| 94 | <p> |
| 95 | <tt>PATH=<the path without the bad program> ./configure ...</tt> |
| 96 | <p> |
| 97 | This is still somewhat inconvenient, but it allows |
| 98 | <tt>configure</tt> to do its work without having to adjust your |
| 99 | <tt>PATH</tt> permanently. |
| 100 | </ol> |
| 101 | |
| 102 | <dt><b>When creating a dynamic library, I get a strange GLIBC error.</b> |
| 103 | <dd> |
| 104 | Under some operating systems (i.e. Linux), libtool does not work correctly |
| 105 | if GCC was compiled with the --disable-shared option. To work around this, |
| 106 | install your own version of GCC that has shared libraries enabled by |
| 107 | default. |
| 108 | <p> |
| 109 | |
| 110 | <dt><b>I've updated my source tree from CVS, and now my build is trying to |
| 111 | use a file/directory that doesn't exist.</b> |
| 112 | <dd> |
| 113 | You need to re-run configure in your object directory. When new Makefiles |
| 114 | are added to the source tree, they have to be copied over to the object |
| 115 | tree in order to be used by the build. |
| 116 | <p> |
| 117 | |
| 118 | <dt><b>I've modified a Makefile in my source tree, but my build tree keeps |
| 119 | using the old version. What do I do?</b> |
| 120 | <dd> |
| 121 | If the Makefile already exists in your object tree, you can just run the |
| 122 | following command in the top level directory of your object tree: |
| 123 | <p> |
| 124 | <tt>./config.status <relative path to Makefile></tt> |
| 125 | <p> |
| 126 | If the Makefile is new, you will have to modify the configure script to copy |
| 127 | it over. |
| 128 | <p> |
| 129 | |
| 130 | <dt><b>I've upgraded to a new version of LLVM, and I get strange build |
| 131 | errors.</b> |
| 132 | <dd> |
| 133 | Sometimes changes to the LLVM source code alters how the build system |
| 134 | works. Changes in libtool, autoconf, or header file dependencies are |
| 135 | especially prone to this sort of problem. |
| 136 | <p> |
| 137 | The best thing to try is to remove the old files and re-build. In most |
| 138 | cases, this takes care of the problem. To do this, just type <tt>make |
| 139 | clean</tt> and then <tt>make</tt> in the directory that fails to build. |
| 140 | <p> |
| 141 | </dl> |
| 142 | <hr> |
| 143 | |
| 144 | </body> |
| 145 | </html> |