LLVM: Frequently Asked Questions

From a6538852d6b89a578ca5002429ccb27277f0734b Mon Sep 17 00:00:00 2001 From: Misha Brukman Date: Thu, 6 Nov 2003 21:55:44 +0000 Subject: [PATCH] * Added a "contents"-like list of questions at the beginning of the file * Use stylsheets. Really, people, work with me here. * Stop using those silly

and whatever else tags * Close tags git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@9760 91177308-0d34-0410-b5e6-96231b3b80d8 --- docs/FAQ.html | 512 ++++++++++++++++++++++++++++++-------------------- 1 file changed, 308 insertions(+), 204 deletions(-) diff --git a/docs/FAQ.html b/docs/FAQ.html index 2ed4441e10b..a40b215f3f9 100644 --- a/docs/FAQ.html +++ b/docs/FAQ.html @@ -1,214 +1,318 @@ - + + + + LLVM: Frequently Asked Questions + + + -
- -LLVM: Frequently Asked Questions - -
+
+ LLVM: Frequently Asked Questions +
-
+
+
License +
+
Why are the LLVM source code and the front-end distributed under different + licenses?
+
Does the University of Illinois Open Source License really qualify as an + "open source" license?
+
Can I modify LLVM source code and redistribute the modified source?
+
Can I modify LLVM source code and redistribute binaries or other tools + based on it, without redistributing the source?
+
- -
-Licenses -
- - -
-
Why are the LLVM source code and the front-end distributed - under different licenses? -
- The C/C++ front-ends are based on GCC and must be distributed under - the GPL. Our aim is to distribute LLVM source code under a much - less restrictive license, in particular one that does not - compel users who distribute tools based on modifying the source to - redistribute the modified source code as well. -
-
Does the University of Illinois Open Source License really qualify - as an "open source" license? -
Yes, the license is - certified - by the Open Source Initiative (OSI). -
-
Can I modify LLVM source code and redistribute the modified - source? -
- Yes. The modified source distribution must retain the - copyright notice and follow the three bulletted conditions listed in - the LLVM license. -
-
Can I modify LLVM source code and redistribute binaries or - other tools based on it, without redistributing the source? -
- Yes, this is why we distribute LLVM under a less restrictive license - than GPL, as explained in the first question above. -
-
-
+
Source code +
+
In what language is LLVM written?
+
How portable is the LLVM source code?
+
- -
-Source Code -
- - -
-
In what language is LLVM written? -
- All of the LLVM tools and libraries are written in C++ with extensive use - of the STL. -
- -
How portable is the LLVM source code? -
- 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. -
- Some porting problems may exist in the following areas: -
-
The GCC front end code is not as portable as the LLVM suite, so it - may not compile as well on unsupported platforms. - -
- -
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. -
- -
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. -
-
+
Build Problems +
+
When I run configure, it finds the wrong C compiler.
+
I compile the code, and I get some error about /localhome.
+
The configure script finds the right C compiler, but it uses the + LLVM linker from a previous build. What do I do?
+
When creating a dynamic library, I get a strange GLIBC error.
+
I've updated my source tree from CVS, and now my build is trying to use a + file/directory that doesn't exist.
+
I've modified a Makefile in my source tree, but my build tree keeps using + the old version. What do I do?
+
I've upgraded to a new version of LLVM, and I get strange build + errors.
+
I've built LLVM and am testing it, but the tests freeze.
+
Why do test results differ when I perform different types of builds?
+
+
-
+ +
+ License +
+ - -
-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. -
- -
I compile the code, and I get some error about /localhome. -
- There are several possible causes for this. The first is that you - didn't set a pathname properly when using configure, and it - defaulted to a pathname that we use on our research machines. -
- 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. - -
The configure script finds the right C compiler, but it - uses the LLVM linker 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 Borne compatible shell, the syntax would be: -
- PATH= ./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 CVS, 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: -
- ./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: -
- gmake ENABLE_PROFILING=1 -
- ...then you must run the tests with the following commands: -
- 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. -
-
+
+
Why are the LLVM source code and the front-end distributed under different +licenses?
+
+ +
+
The C/C++ front-ends are based on GCC and must be distributed under the GPL. +Our aim is to distribute LLVM source code under a much less restrictive +license, in particular one that does not compel users who distribute tools based +on modifying the source to redistribute the modified source code as well.
+
+ +
+
Does the University of Illinois Open Source License really qualify as an +"open source" license?
+
+ +
+
Yes, the license is certified by the Open +Source Initiative (OSI).
+
+ +
+
Can I modify LLVM source code and redistribute the modified source?
+
+ +
+
Yes. The modified source distribution must retain the copyright notice and +follow the three bulletted conditions listed in the LLVM license.
+
+ +
+
Can I modify LLVM source code and redistribute binaries or other tools based +on it, without redistributing the source?
+
+ +
+
Yes, this is why we distribute LLVM under a less restrictive license than +GPL, as explained in the first question above.
+
+ + +
+ Source Code +
+ + +
+
In what language is LLVM written?
+
+ +
+
All of the LLVM tools and libraries are written in C++ with extensive use of +the STL.
+
+ +
+
How portable is the LLVM source code?
+
+ +
+
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.
+ +
Some porting problems may exist in the following areas:
+ +
+ +
The GCC front end code is not as portable as the LLVM suite, so it may not + compile as well on unsupported platforms.
+ +
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.
+ +
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.
+ +
+ +
+ + +
+ 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.
+ +
+ +
+
I compile the code, and I get some error about /localhome.
+
+ +
+ +
There are several possible causes for this. The first is that you didn't set +a pathname properly when using configure, and it defaulted to a +pathname that we use on our research machines.
+ +
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.
+ +
+ +
+
The configure script finds the right C compiler, but it uses the +LLVM linker 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:
-The LLVM Compiler Infrastructure -
+
+ +
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 Borne compatible shell, the syntax would be:
+ +
PATH= ./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 CVS, 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:
+ +
./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:
+ +
gmake ENABLE_PROFILING=1 + +
...then you must run the tests with the following commands:
+ +
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.
+ +
+ + + +
+
+ The LLVM Compiler Infrastructure +
+ Last modified: $Date$ +
-- 2.34.1

- -LLVM: Frequently Asked Questions - -

-Licenses -

-Source Code -

-Build Problems -