Using The LLVM Libraries

1. Abstract
2. Introduction
3. Library Descriptions
4. Library Dependencies
5. Linkage Rules Of Thumb
   1. Always link LLVMCore, LLVMSupport, LLVMSystem
   2. Never link both archive and re-linked

Written by Reid Spencer

Warning: This document is out of date, for more information please see llvm-config or, if you use CMake, the CMake LLVM guide.

Abstract

Amongst other things, LLVM is a toolkit for building compilers, linkers, runtime executives, virtual machines, and other program execution related tools. In addition to the LLVM tool set, the functionality of LLVM is available through a set of libraries. To use LLVM as a toolkit for constructing tools, a developer needs to understand what is contained in the various libraries, what they depend on, and how to use them. Fortunately, there is a tool, `llvm-config` to aid with this. This document describes the contents of the libraries and how to use `llvm-config` to generate command line options.

Introduction

If you're writing a compiler, virtual machine, or any other utility based on LLVM, you'll need to figure out which of the many libraries files you will need to link with to be successful. An understanding of the contents of these libraries will be useful in coming up with an optimal specification for the libraries to link with. The purpose of this document is to reduce some of the trial and error that the author experienced in using LLVM.

LLVM produces two types of libraries: archives (ending in `.a`) and objects (ending in `.o`). However, both are libraries. Libraries ending in `.o` are known as re-linked libraries because they contain all the compilation units of the library linked together as a single `.o` file. Furthermore, several of the libraries have both forms of library. The re-linked libraries are used whenever you want to include all symbols from the library. The archive libraries are used whenever you want to only resolve outstanding symbols at that point in the link without including everything in the library.

If you're using the LLVM Makefile system to link your tools,you will use the `LLVMLIBS` make variable. (see the Makefile Guide for details). This variable specifies which LLVM libraries to link into your tool and the order in which they will be linked. You specify re-linked libraries by naming the library without a suffix. You specify archive libraries by naming the library with a `.a` suffix but without the `lib` prefix. The order in which the libraries appear in the `LLVMLIBS` variable definition is the order in which they will be linked. Getting this order correct for your tool can sometimes be challenging.

Library Descriptions

The table below categorizes each library

Library | Forms | Description
--- | --- | ---
Core Libraries
LLVMArchive | `.a` | LLVM archive reading and writing
LLVMAsmParser | `.a` | LLVM assembly parsing
LLVMBCReader | `.a` | LLVM bitcode reading
LLVMBCWriter | `.a` | LLVM bitcode writing
LLVMCore | `.a` | LLVM core intermediate representation
LLVMDebugger | `.a` | Source level debugging support
LLVMLinker | `.a` | Bitcode and archive linking interface
LLVMSupport | `.a` | General support utilities
LLVMSystem | `.a` | Operating system abstraction layer
LLVMbzip2 | `.a` | BZip2 compression library
Analysis Libraries
LLVMAnalysis | `.a` | Various analysis passes.
LLVMDataStructure | `.o` | Data structure analysis passes.
LLVMipa | `.a` | Inter-procedural analysis passes.
Transformation Libraries
LLVMInstrumentation | `.a` | Instrumentation passes.
LLVMipo | `.a` | All inter-procedural optimization passes.
LLVMScalarOpts | `.a` | All scalar optimization passes.
LLVMTransformUtils | `.a` | Transformation utilities used by many passes.
Code Generation Libraries
LLVMCodeGen | `.o` | Native code generation infrastructure
LLVMSelectionDAG | `.o` | Aggressive instruction selector for directed acyclic graphs
Target Libraries
LLVMAlpha | `.o` | Code generation for Alpha architecture
LLVMARM | `.o` | Code generation for ARM architecture
LLVMCBackend | `.o` | 'C' language code generator.
LLVMPowerPC | `.o` | Code generation for PowerPC architecture
LLVMSparc | `.o` | Code generation for Sparc architecture
LLVMTarget | `.a` | Generic code generation utilities.
LLVMX86 | `.o` | Code generation for Intel x86 architecture
Runtime Libraries
LLVMInterpreter | `.o` | Bitcode Interpreter
LLVMJIT | `.o` | Bitcode JIT Compiler
LLVMExecutionEngine | `.o` | Virtual machine engine

Using llvm-config

The `llvm-config` tool is a perl script that produces on its output various kinds of information. For example, the source or object directories used to build LLVM can be accessed by passing options to `llvm-config`. For complete details on this tool, please see the manual page.

To understand the relationships between libraries, the `llvm-config` can be very useful. If all you know is that you want certain libraries to be available, you can generate the complete set of libraries to link with using one of four options, as below:

1. `--ldflags`. This generates the command line options necessary to be passed to the `ld` tool in order to link with LLVM. Most notably, the `-L` option is provided to specify a library search directory that contains the LLVM libraries.
2. `--libs`. This generates command line options suitable for use with a gcc-style linker. That is, libraries are given with a -l option and object files are given with a full path.
3. `--libnames`. This generates a list of just the library file names. If you know the directory in which these files reside (see --ldflags) then you can find the libraries there.
4. `--libfiles`. This generates the full path names of the LLVM library files.

If you wish to delve further into how `llvm-config` generates the correct order (based on library dependencies), please see the tool named `GenLibDeps.pl` in the `utils` source directory of LLVM.

## Dependency Relationships Of Libraries

This graph shows the dependency of archive libraries on other archive libraries or objects. Where a library has both archive and object forms, only the archive form is shown.

## Dependency Relationships Of Object Files

This graph shows the dependency of object files on archive libraries or other objects. Where a library has both object and archive forms, only the dependency to the archive form is shown.

The following list shows the dependency relationships between libraries in textual form. The information is the same as shown on the graphs but arranged alphabetically.

libLLVMAnalysis.a
  - libLLVMCore.a
  - libLLVMSupport.a
  - libLLVMSystem.a
  - libLLVMTarget.a
libLLVMArchive.a
  - libLLVMBCReader.a
  - libLLVMCore.a
  - libLLVMSupport.a
  - libLLVMSystem.a
libLLVMAsmParser.a
  - libLLVMCore.a
  - libLLVMSystem.a
libLLVMBCReader.a
  - libLLVMCore.a
  - libLLVMSupport.a
  - libLLVMSystem.a
libLLVMBCWriter.a
  - libLLVMCore.a
  - libLLVMSupport.a
  - libLLVMSystem.a
libLLVMCodeGen.a
  - libLLVMAnalysis.a
  - libLLVMCore.a
  - libLLVMScalarOpts.a
  - libLLVMSupport.a
  - libLLVMSystem.a
  - libLLVMTarget.a
  - libLLVMTransformUtils.a
libLLVMCore.a
  - libLLVMSupport.a
  - libLLVMSystem.a
libLLVMDebugger.a
  - libLLVMBCReader.a
  - libLLVMCore.a
  - libLLVMSupport.a
  - libLLVMSystem.a
libLLVMInstrumentation.a
  - libLLVMCore.a
  - libLLVMScalarOpts.a
  - libLLVMSupport.a
  - libLLVMTransformUtils.a
libLLVMLinker.a
  - libLLVMArchive.a
  - libLLVMBCReader.a
  - libLLVMCore.a
  - libLLVMSupport.a
  - libLLVMSystem.a
libLLVMScalarOpts.a
  - libLLVMAnalysis.a
  - libLLVMCore.a
  - libLLVMSupport.a
  - libLLVMSystem.a
  - libLLVMTarget.a
  - libLLVMTransformUtils.a
libLLVMSelectionDAG.a
  - libLLVMAnalysis.a
  - libLLVMCodeGen.a
  - libLLVMCore.a
  - libLLVMSupport.a
  - libLLVMSystem.a
  - libLLVMTarget.a
  - libLLVMTransformUtils.a
libLLVMSupport.a
  - libLLVMSystem.a
  - libLLVMbzip2.a
libLLVMSystem.a
libLLVMTarget.a
  - libLLVMCore.a
  - libLLVMSupport.a
  - libLLVMSystem.a
libLLVMTransformUtils.a
  - libLLVMAnalysis.a
  - libLLVMCore.a
  - libLLVMSupport.a
  - libLLVMSystem.a
  - libLLVMTarget.a
  - libLLVMipa.a
libLLVMbzip2.a
libLLVMipa.a
  - libLLVMAnalysis.a
  - libLLVMCore.a
  - libLLVMSupport.a
  - libLLVMSystem.a
libLLVMipo.a
  - libLLVMAnalysis.a
  - libLLVMCore.a
  - libLLVMSupport.a
  - libLLVMSystem.a
  - libLLVMTarget.a
  - libLLVMTransformUtils.a
  - libLLVMipa.a
libLLVMlto.a
  - libLLVMAnalysis.a
  - libLLVMBCReader.a
  - libLLVMBCWriter.a
  - libLLVMCore.a
  - libLLVMLinker.a
  - libLLVMScalarOpts.a
  - libLLVMSupport.a
  - libLLVMSystem.a
  - libLLVMTarget.a
  - libLLVMipa.a
  - libLLVMipo.a
LLVMARM.o
  - libLLVMCodeGen.a
  - libLLVMCore.a
  - libLLVMSelectionDAG.a
  - libLLVMSupport.a
  - libLLVMSystem.a
  - libLLVMTarget.a
LLVMAlpha.o
  - libLLVMCodeGen.a
  - libLLVMCore.a
  - libLLVMSelectionDAG.a
  - libLLVMSupport.a
  - libLLVMSystem.a
  - libLLVMTarget.a
LLVMCBackend.o
  - libLLVMAnalysis.a
  - libLLVMCodeGen.a
  - libLLVMCore.a
  - libLLVMScalarOpts.a
  - libLLVMSupport.a
  - libLLVMSystem.a
  - libLLVMTarget.a
  - libLLVMTransformUtils.a
  - libLLVMipa.a
LLVMExecutionEngine.o
  - libLLVMCore.a
  - libLLVMSupport.a
  - libLLVMSystem.a
  - libLLVMTarget.a
LLVMInterpreter.o
  - LLVMExecutionEngine.o
  - libLLVMCodeGen.a
  - libLLVMCore.a
  - libLLVMSupport.a
  - libLLVMSystem.a
  - libLLVMTarget.a
LLVMJIT.o
  - LLVMExecutionEngine.o
  - libLLVMCore.a
  - libLLVMSupport.a
  - libLLVMSystem.a
  - libLLVMTarget.a
LLVMPowerPC.o
  - libLLVMCodeGen.a
  - libLLVMCore.a
  - libLLVMSelectionDAG.a
  - libLLVMSupport.a
  - libLLVMSystem.a
  - libLLVMTarget.a
LLVMSparc.o
  - libLLVMCodeGen.a
  - libLLVMCore.a
  - libLLVMSelectionDAG.a
  - libLLVMSupport.a
  - libLLVMSystem.a
  - libLLVMTarget.a
LLVMX86.o
  - libLLVMCodeGen.a
  - libLLVMCore.a
  - libLLVMSelectionDAG.a
  - libLLVMSupport.a
  - libLLVMSystem.a
  - libLLVMTarget.a

Linkage Rules Of Thumb

This section contains various "rules of thumb" about what files you should link into your programs.

Always Link LLVMCore, LLVMSupport, and LLVMSystem

No matter what you do with LLVM, the last three entries in the value of your LLVMLIBS make variable should always be: `LLVMCore LLVMSupport.a LLVMSystem.a`. There are no `LLVM` programs that don't depend on these three.

Never link both archive and re-linked library

There is never any point to linking both the re-linked (`.o`) and the archive (`.a`) versions of a library. Since the re-linked version includes the entire library, the archive version will not resolve any symbols. You could even end up with link error if you place the archive version before the re-linked version on the linker's command line.