gccld - optimizing LLVM linker

gccld [options] filename ...

The gccld utility takes a set of LLVM bytecode files and links them together into a single LLVM bytecode file. The output bytecode file can be another bytecode library or an executable bytecode program. Using additional options, gccld is able to produce native code executables.

The gccld utility is primarily used by the llvmgcc and llvmg++ front-ends, and as such, attempts to mimic the interface provided by the default system linker so that it can act as a ``drop-in'' replacement.

The gccld tool performs a small set of interprocedural, post-link optimizations on the program.

When looking for objects specified on the command line, gccld will search for the object first in the current directory and then in the directory specified by the LLVM_LIB_SEARCH_PATH environment variable. If it cannot find the object, it fails.

When looking for a library specified with the -l option, gccld first attempts to load a file with that name from the current directory. If that fails, it looks for liblibrary.bc, liblibrary.a, or liblibrary.shared library extension, in that order, in each directory added to the library search path with the -L option. These directories are searched in the order they were specified. If the library cannot be located, then gccld looks in the directory specified by the LLVM_LIB_SEARCH_PATH environment variable. If it does not find a library there, it fails.

The shared library extension may be .so, .dyld, .dll, or something different, depending upon the system.

The -L option is global. It does not matter where it is specified in the list of command line arguments; the directory is simply added to the search path and is applied to all libraries, preceding or succeeding, in the command line.

All object files are linked first in the order they were specified on the command line. All library files are linked next. Some libraries may not be linked into the object program; see below.

Object files and static bytecode objects are always linked into the output file. Library archives (.a files) load only the objects within the archive that define symbols needed by the output file. Hence, libraries should be listed after the object files and libraries which need them; otherwise, the library may not be linked in, and the dependent library will not have its undefined symbols defined.

The gccld program has limited support for native code generation, when using the -native or -native-cbe options.

-help

Print a summary of command line options.

-o filename

Specify the output filename which will hold the linked bytecode.

-stats

Print statistics.

-time-passes

Record the amount of time needed for each pass and print it to standard error.

-verify

Verify each pass result.

-disable-opt

Disable all link-time optimization passes.

-disable-inlining

Do not run the inliner pass.

-Ldirectory

Add directory to the list of directories to search when looking for libraries.

-disable-internalize

Do not mark all symbols as internal.

-internalize-public-api-file filename

Preserve the list of symbol names in the file filename.

-internalize-public-api-list <list>

Preserve the symbol names in list.

-llibrary

Specify libraries to include when linking the output file. When linking, gccld will first attempt to load a file with the pathname library. If that fails, it will then attempt to load liblibrary.bc, liblibrary.a, and liblibrary.shared library extension, in that order.

-link-as-library

Link the .bc files together as a library, not an executable.

-native

Generate a native machine code executable. When generating native executables, gccld first checks for a bytecode version of the library and links it in, if necessary. If the library is missing, gccld skips it. Then, gccld links in the same libraries as native code. In this way, gccld should be able to link in optimized bytecode subsets of common libraries and then link in any part of the library that hasn't been converted to bytecode.

-native-cbe

Generate a native machine code executable with the LLVM C backend. This option is identical to the -native option, but uses the C backend to generate code for the program instead of an LLVM native code generator.

-s

Strip symbol information from the generated executable.

-v

Print information about actions taken.

If gccld succeeds, it will exit with an exit status of 0. Otherwise, if an error occurs, it will exit with a non-zero exit status.

llvm-link, gccas

Maintained by the LLVM Team (<http://llvm.cs.uiuc.edu>).