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 +
+ +
    +
  1. License +
      +
    1. Why are the LLVM source code and the front-end distributed under different + licenses?
      2. +
    2. Does the University of Illinois Open Source License really qualify as an + "open source" license?
      3. +
    3. Can I modify LLVM source code and redistribute the modified source?
      4. +
    4. Can I modify LLVM source code and redistribute binaries or other tools + based on it, without redistributing the source?
      5. +
    2. + +
  2. Source code +
      +
    1. In what language is LLVM written?
      2. +
    2. How portable is the LLVM source code?
      3. +
    3. + +
  3. Build Problems +
      +
    1. When I run configure, it finds the wrong C compiler.
      2. +
    2. I compile the code, and I get some error about /localhome.
      3. +
    3. The configure script finds the right C compiler, but it uses the + LLVM linker from a previous build. What do I do?
      4. +
    4. When creating a dynamic library, I get a strange GLIBC error.
      5. +
    5. I've updated my source tree from CVS, and now my build is trying to use a + file/directory that doesn't exist.
      6. +
    6. I've modified a Makefile in my source tree, but my build tree keeps using + the old version. What do I do?
      7. +
    7. I've upgraded to a new version of LLVM, and I get strange build + errors.
      8. +
    8. I've built LLVM and am testing it, but the tests freeze.
      9. +
    9. Why do test results differ when I perform different types of builds?
      10. +
    4. +
+ + +
+ License +
+ + +
+

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:

+ + + +
+ + +
+ 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:

+ +
    + +

  1. 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.

    2. + +

  2. 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.

    3. + +
+ +
+ +
+

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.

+ +
+ +
- - -

-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? -
- 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: -

-
- -
- - -

-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: -
    -
  1. 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. -

    - -

  2. 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 -
+
+ The LLVM Compiler Infrastructure +
+ Last modified: $Date$ +