Bootstrapping the LLVM C/C++ Front-End

- -

This document is intended to explain the process of building the LLVM C/C++ -front-end from its source code. You have to do this, for example, if you are -porting LLVM to a new architecture or operating system, if you are working from -Top-Of-Tree CVS/SVN, or if there is no precompiled snapshot available.

- -

NOTE: This is currently a somewhat fragile, error-prone process, and -you should only try to do it if:

- -

you really, really, really can't use the - binaries we distribute
you are an elite GCC hacker.
you want to use the latest bits from CVS.

- -

We welcome patches to help make this process simpler.

- -

If you are building LLVM and the GCC front-end under Cygwin, please note that -the LLVM and GCC makefiles do not correctly handle spaces in paths. To deal -with this issue, make sure that your LLVM and GCC source and build trees are -located in a top-level directory (like /cygdrive/c/llvm and -/cygdrive/c/llvm-cfrontend), not in a directory that contains a space -(which includes your "home directory", because it lives under the "Documents and -Settings" directory). We welcome patches to fix this issue.

- -

It has been found that the GCC 3.3.3 compiler provided with recent Cygwin -versions is incapable of compiling the LLVM GCC front-end correctly. If your -Cygwin installation includes GCC 3.3.3, we strongly recommend that you -download GCC 3.4.3, build it separately, and use it for compiling the LLVM GCC -front-end. This has been shown to work correctly.

- -

Some versions of Cygwin utilize an experimental version of GNU binutils that -will cause the GNU ld linker to fail an assertion when linking -components of the libstdc++. It is recommended that you replace the entire -binutils package with version 2.15 such that "ld --version" responds -with

- -

-

GNU ld version 2.15

-

- -

not with:

- -

-

GNU ld version 2.15.91 20040725

-

- -

If you are building LLVM and the GCC front-end under AIX, do NOT use GNU -Binutils. They are not stable under AIX and may produce incorrect and/or -invalid code. Instead, use the system assembler and linker.

- -

This section describes how to aquire and build llvm-gcc4, which is based on -the GCC 4.0.1 front-end. This front-end supports C, C++, Objective-C, and -Objective-C++. Note that the instructions for building this front-end are -completely different than those for building llvm-gcc3.

- -

Retrieve the appropriate llvm-gcc4-x.y.source.tar.gz archive from the - llvm web site.
- -
It is also possible to download the sources of the llvm-gcc4 front end - from a read-only mirror using subversion. To check out the code the - first time use:
- -
-
```
-svn co svn://anonsvn.opensource.apple.com/svn/llvm/trunk dst-directory
-
```
-
- -
After that, the code can be be updated in the destination directory - using:
- -
-
```
svn update
```
-
- -
The mirror is brought up to date every evening.
Follow the directions in the top-level README.LLVM file for - up-to-date instructions on how to build llvm-gcc4.

- -

Aquire llvm-gcc3 from LLVM CVS - or from a release tarball.
Configure and build the LLVM libraries and tools. There are two ways to - do this: either with objdir == srcdir or - objdir != srcdir. It is recommended that - srcdir be the same as objdir for your - LLVM tree (but note that you should always use srcdir != - objdir for llvm-gcc):
- -
- With objdir != srcdir:
  - -
  -
```
-% cd objdir
-% srcdir/configure --prefix=/some/path/you/can/install/to [options...]
-% gmake tools-only
-
```
  -
  -
- With objdir == srcdir:
  - -
  -
```
-% cd llvm
-% ./configure --prefix=/some/path/you/can/install/to [options...]
-% gmake tools-only
-
```
  -
  -
- -
This will build all of the LLVM tools and libraries. The - --prefix option defaults to /usr/local (per configure - standards) but unless you are a system administrator, you probably - won't be able to install LLVM there because of permissions. Specify a - path into which LLVM can be installed - (e.g. --prefix=/home/user/llvm).

Add the directory containing the tools to your PATH.

- -

-csh: -

-  % set path = ( `cd llvm/Debug/bin && pwd` $path )
-

-sh: -

-  % export PATH=`cd llvm/Debug/bin && pwd`:$PATH
-

-

Unpack the C/C++ front-end source, either by - untar'ing/unzipping a tar.gz file or checking out CVS into this - directory.

Make "build" and "install" directories as siblings of the "src" - tree:

- -

-csh: -

-  % pwd
-  /usr/local/example/llvm-gcc3.4/src
-  % cd ..
-  % mkdir build install
-  % set CFEINSTALL = `pwd`/install
-

-sh: -

-  % pwd
-  /usr/local/example/llvm-gcc3.4/src
-  % cd ..
-  % mkdir build install
-  % export CFEINSTALL=`pwd`/install
-

-

Configure, build, and install the GCC front-end:
- -
- Linux/x86:
- Linux/IA-64:
- MacOS X/PowerPC (requires dlcompat library):
- AIX/PowerPC: -
- -
-
```
-% cd build
-% ../src/configure --prefix=$CFEINSTALL --disable-threads --disable-nls \
-  --disable-shared --enable-languages=c,c++ --program-prefix=llvm-
-% gmake all; gmake install
-
```
-
- -
Cygwin/x86:
- -
-
```
-% cd build
-% ../src/configure --prefix=$CFEINSTALL --disable-threads --disable-nls \
-  --disable-shared --enable-languages=c,c++ --disable-c-mbchar \
-  --program-prefix=llvm-
-% gmake all; gmake install
-
```
-
- -
Solaris/SPARC:
- -
The GCC front-end can be configured for either SPARC V8 (32 bit) or - SPARC V9 (64 bit). This changes, among other things, the sizes of - integer types and the macros defined for conditional compilation.
- -
The SPARC V8 ABI support is more robust than the V9 ABI support and can - generate SPARC V9 code. It is highly recommended that you use the V8 - ABI with LLVM, as shown below. Also, note that Solaris has trouble - with various wide (multibyte) character functions from C as referenced - from C++, so we typically configure with --disable-c-mbchar (cf. Bug 206).
- -
-
```
-% cd build
-% ../src/configure --prefix=$CFEINSTALL --disable-threads --disable-nls \
-  --disable-shared --enable-languages=c,c++ --host=sparc-sun-solaris2.8 \
-  --disable-c-mbchar --program-prefix=llvm-
-% gmake all; gmake install
-
```
-
- -
Common Problem: You may get error messages regarding the fact - that LLVM does not support inline assembly. Here are two common - fixes:
- -
- Fix 1: If you have system header files that include inline - assembly, you may have to modify them to remove the inline assembly - and install the modified versions in - $CFEINSTALL/lib/gcc/target-triplet/3.4-llvm/include.
- Fix 2: If you are building the C++ front-end on a CPU we - haven't tried yet, you will probably have to edit the appropriate - version of atomicity.h under - src/libstdc++-v3/config/cpu/name-of-cpu/atomicity.h - and apply a patch so that it does not use inline assembly.
- -
Porting to a new architecture: If you are porting the front-end - to a new architecture or compiling in a configuration that we have not - tried previously, there are probably several changes you will have to - make to the GCC target to get it to work correctly. These include:
- -
- Often targets include special assembler or linker flags which - llvm-as, opt, or llvm-ld do not - understand. In general, these can just be removed.
- LLVM currently does not support any floating point values other than - 32-bit and 64-bit IEEE floating point. The primary effect of this - is that you may have to map "long double" onto "double".
- The profiling hooks in GCC do not apply at all to the LLVM - front-end. These may need to be disabled.
- No inline assembly for position independent code. At the LLVM - level, everything is position independent.
- We handle .init and .fini differently.
- You may have to disable multilib support in your target. Using - multilib support causes the GCC compiler driver to add a lot of - "-L" options to the link line, which do not relate to - LLVM. To disable multilibs, delete any - MULTILIB_OPTIONS lines from your target files.
- Did we mention that we don't support inline assembly? You'll - probably have to add some fixinclude hacks to disable it in the - system headers.

Put $CFEINSTALL/bin into your PATH environment - variable.

- -

-csh: -

-  % setenv PATH $CFEINSTALL/bin:$PATH
-

-sh: -

-  % export PATH=$CFEINSTALL/bin:$PATH
-

-

Go back into the LLVM source tree proper. Rerun configure, using the - same options as the last time. This will cause the configuration to now - find the newly built llvm-gcc and llvm-g++ executables.
Rebuild your CVS tree. This shouldn't cause the whole thing to be - rebuilt, but it should build the runtime libraries. After the tree is - built, install the runtime libraries into your GCC front-end build tree. - These are the commands you need:
- -
-
```
-% gmake
-% gmake -C runtime install-bytecode
-
```
-
-
Optionally, build a symbol table for the newly installed runtime - libraries. Although this step is optional, you are strongly encouraged to - do this as the symbol tables will make a significant difference in your - link times. Use the llvm-ranlib tool to do this, as follows:
- -
-
```
-% cd $CFEINSTALL/lib
-% llvm-ranlib libiberty.a
-% llvm-ranlib libstdc++.a
-% llvm-ranlib libsupc++.a
-% cd $CFEINSTALL/lib/gcc/target-triplet/3.4-llvm
-% llvm-ranlib libgcc.a
-% llvm-ranlib libgcov.a
-
```
-
-
Test the newly-installed C frontend by one or more of the following - means:
- -
- running the feature & regression tests via make - check
- compiling and running a "hello, LLVM" program in C and C++.
- running the tests found in the llvm-test CVS module

- -

-

-The LLVM GCC frontend is licensed to you under the GNU General Public License -and the GNU Lesser General Public License. Please see the files COPYING and -COPYING.LIB for more details. -

- -

-More information is available in the FAQ. -

- +This page has moved here.