llvm-ld - LLVM linker
llvm-ld <options> <files>
The llvm-ld tool takes a set of LLVM bitcode files and links them together into a single LLVM bitcode file. The output bitcode file can be another bitcode file or an executable bitcode program. Using additional options, llvm-ld is able to produce native code executables.
The llvm-ld tool is the main linker for LLVM. It is used to link together the output of LLVM front-end compilers and run ``link time'' optimizations (mostly the inter-procedural kind).
The llvm-ld tools attempts to mimic the interface provided by the default system linker so that it can act as a drop-in replacement.
When looking for objects specified on the command line, llvm-ld 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, llvm-ld 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 are specified. If the library cannot be located, then llvm-ld 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 and bitcode 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 bitcode 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 llvm-ld program has limited support for native code generation, when using the -native or -native-cbe options. Native code generation is performed by converting the linked bitcode into native assembly (.s) or C code and running the system compiler (typically gcc) on the result.
When generating native executables, llvm-ld first checks for a bitcode version of the library and links it in, if necessary. If the library is missing, llvm-ld skips it. Then, llvm-ld links in the same libraries as native code.
In this way, llvm-ld should be able to link in optimized bitcode subsets of common libraries and then link in any part of the library that hasn't been converted to bitcode.
This option is identical to the B<-native> option, but uses the C backend to generate code for the program instead of an LLVM native code generator.
#!/bin/bash
cp $1 $2
If llvm-ld succeeds, it will exit with 0 return code. If an error occurs, it will exit with a non-zero return code.
The LLVM_LIB_SEARCH_PATH environment variable is used to find bitcode
libraries. Any paths specified in this variable will be searched after the -L
options.
Maintained by the LLVM Team (http://llvm.org).