diff options
| -rw-r--r-- | llvm/docs/FAQ.rst | 125 |
1 files changed, 0 insertions, 125 deletions
diff --git a/llvm/docs/FAQ.rst b/llvm/docs/FAQ.rst index 78c5440af31..0ab99f3452a 100644 --- a/llvm/docs/FAQ.rst +++ b/llvm/docs/FAQ.rst @@ -75,131 +75,6 @@ reference. In fact, the names of dummy numbered temporaries like ``%1`` are not explicitly represented in the in-memory representation at all (see ``Value::getName()``). -Build Problems -============== - -When I run configure, it finds the wrong C compiler. ----------------------------------------------------- -The ``configure`` script attempts to locate first ``gcc`` and then ``cc``, -unless it finds compiler paths set in ``CC`` and ``CXX`` for the C and C++ -compiler, respectively. - -If ``configure`` finds the wrong compiler, either adjust your ``PATH`` -environment variable or set ``CC`` and ``CXX`` explicitly. - - -The ``configure`` script finds the right C compiler, but it uses the LLVM tools from a previous build. What do I do? ---------------------------------------------------------------------------------------------------------------------- -The ``configure`` script uses the ``PATH`` to find executables, so if it's -grabbing the wrong linker/assembler/etc, there are two ways to fix it: - -#. Adjust your ``PATH`` environment variable so that the correct program - appears first in the ``PATH``. This may work, but may not be convenient - when you want them *first* in your path for other work. - -#. Run ``configure`` with an alternative ``PATH`` that is correct. In a - Bourne compatible shell, the syntax would be: - -.. code-block:: console - - % PATH=[the path without the bad program] $LLVM_SRC_DIR/configure ... - -This is still somewhat inconvenient, but it allows ``configure`` to do its -work without having to adjust your ``PATH`` permanently. - - -When creating a dynamic library, I get a strange GLIBC error. -------------------------------------------------------------- -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. - - -I've updated my source tree from Subversion, and now my build is trying to use a file/directory that doesn't exist. -------------------------------------------------------------------------------------------------------------------- -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. - - -I've modified a Makefile in my source tree, but my build tree keeps using the old version. What do I do? ---------------------------------------------------------------------------------------------------------- -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: - -.. code-block:: console - - % ./config.status <relative path to Makefile>; - -If the Makefile is new, you will have to modify the configure script to copy -it over. - - -I've upgraded to a new version of LLVM, and I get strange build errors. ------------------------------------------------------------------------ -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. - -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 ``make clean`` and then -``make`` in the directory that fails to build. - - -I've built LLVM and am testing it, but the tests freeze. --------------------------------------------------------- -This is most likely occurring because you built a profile or release -(optimized) build of LLVM and have not specified the same information on the -``gmake`` command line. - -For example, if you built LLVM with the command: - -.. code-block:: console - - % gmake ENABLE_PROFILING=1 - -...then you must run the tests with the following commands: - -.. code-block:: console - - % cd llvm/test - % gmake ENABLE_PROFILING=1 - -Why do test results differ when I perform different types of builds? --------------------------------------------------------------------- -The LLVM test suite is dependent upon several features of the LLVM tools and -libraries. - -First, the debugging assertions in code are not enabled in optimized or -profiling builds. Hence, tests that used to fail may pass. - -Second, some tests may rely upon debugging options or behavior that is only -available in the debug build. These tests will fail in an optimized or -profile build. - - -After Subversion update, rebuilding gives the error "No rule to make target". ------------------------------------------------------------------------------ -If the error is of the form: - -.. code-block:: console - - gmake[2]: *** No rule to make target `/path/to/somefile', - needed by `/path/to/another/file.d'. - Stop. - -This may occur anytime files are moved within the Subversion repository or -removed entirely. In this case, the best solution is to erase all ``.d`` -files, which list dependencies for source files, and rebuild: - -.. code-block:: console - - % cd $LLVM_OBJ_DIR - % rm -f `find . -name \*\.d` - % gmake - -In other cases, it may be necessary to run ``make clean`` before rebuilding. - Source Languages ================ |
