These options come into play when the compiler links object files into an executable output file. They are meaningless if the compiler is not doing a link step.
-c
-S
-E
-flinker-output=
typeIf type is ‘exec’ the code generation is configured to produce static binary. In this case -fpic and -fpie are both disabled.
If type is ‘dyn’ the code generation is configured to produce shared library. In this case -fpic or -fPIC is preserved, but not enabled automatically. This makes it possible to build shared libraries without position independent code on architectures this is possible, i.e. on x86.
If type is ‘pie’ the code generation is configured to produce -fpie executable. This result in similar optimizations as ‘exec’ except that -fpie is not disabled if specified at compilation time.
If type is ‘rel’ the compiler assumes that incremental linking is done. The sections containing intermediate code for link-time optimization are merged, pre-optimized, and output to the resulting object file. In addition, if -ffat-lto-objects is specified the binary code is produced for future non-lto linking. The object file produced by incremental linking will be smaller than a static library produced from the same object files. At link-time the result of incremental linking will also load faster to compiler than a static library assuming that majority of objects in the library are used.
Finally ‘nolto-rel’ configure compiler to for incremental linking where code generation is forced, final binary is produced and the intermediate code for later link-time optimization is stripped. When multiple object files are linked together the resulting code will be optimized better than with link time optimizations disabled (for example, the cross-module inlining will happen), most of benefits of whole program optimizations are however lost.
During the incremental link (by -r) the linker plugin will default to
rel. With current interfaces to GNU Binutils it is however not
possible to link incrementally LTO objects and non-LTO objects into a single
mixed object file. In the case any of object files in incremental link cannot
be used for link-time optimization the linker plugin will output warning and
use ‘nolto-rel’. To maintain the whole program optimization it is
recommended to link such objects into static library instead. Alternatively it
is possible to use H.J. Lu's binutils with support for mixed objects.
-fuse-ld=bfd
-fuse-ld=gold
-fuse-ld=lld
-l
library-l
libraryThe -l option is passed directly to the linker by GCC. Refer to your linker documentation for exact details. The general description below applies to the GNU linker.
The linker searches a standard list of directories for the library. The directories searched include several standard system directories plus any that you specify with -L.
Static libraries are archives of object files, and have file names like liblibrary.a. Some targets also support shared libraries, which typically have names like liblibrary.so. If both static and shared libraries are found, the linker gives preference to linking with the shared library unless the -static option is used.
It makes a difference where in the command you write this option; the
linker searches and processes libraries and object files in the order they
are specified. Thus, ‘foo.o -lz bar.o’ searches library ‘z’
after file foo.o but before bar.o. If bar.o refers
to functions in ‘z’, those functions may not be loaded.
-lobjc
-nostartfiles
-nodefaultlibs
The compiler may generate calls to memcmp
,
memset
, memcpy
and memmove
.
These entries are usually resolved by entries in
libc. These entry points should be supplied through some other
mechanism when this option is specified.
-nolibc
-nostdlib
The compiler may generate calls to memcmp
, memset
,
memcpy
and memmove
.
These entries are usually resolved by entries in
libc. These entry points should be supplied through some other
mechanism when this option is specified.
One of the standard libraries bypassed by -nostdlib and
-nodefaultlibs is libgcc.a, a library of internal subroutines
which GCC uses to overcome shortcomings of particular machines, or special
needs for some languages.
(See Interfacing to GCC Output,
for more discussion of libgcc.a.)
In most cases, you need libgcc.a even when you want to avoid
other standard libraries. In other words, when you specify -nostdlib
or -nodefaultlibs you should usually specify -lgcc as well.
This ensures that you have no unresolved references to internal GCC
library subroutines.
(An example of such an internal subroutine is __main
, used to ensure C++
constructors are called; see collect2
.)
-e
entry--entry=
entry-pie
-no-pie
-static-pie
-pthread
-r
-rdynamic
dlopen
or to allow obtaining backtraces
from within a program.
-s
-static
-shared
-shared-libgcc
-static-libgcc
There are several situations in which an application should use the shared libgcc instead of the static version. The most common of these is when the application wishes to throw and catch exceptions across different shared libraries. In that case, each of the libraries as well as the application itself should use the shared libgcc.
Therefore, the G++ driver automatically adds -shared-libgcc whenever you build a shared library or a main executable, because C++ programs typically use exceptions, so this is the right thing to do.
If, instead, you use the GCC driver to create shared libraries, you may find that they are not always linked with the shared libgcc. If GCC finds, at its configuration time, that you have a non-GNU linker or a GNU linker that does not support option --eh-frame-hdr, it links the shared version of libgcc into shared libraries by default. Otherwise, it takes advantage of the linker and optimizes away the linking with the shared version of libgcc, linking with the static version of libgcc by default. This allows exceptions to propagate through such shared libraries, without incurring relocation costs at library load time.
However, if a library or main executable is supposed to throw or catch
exceptions, you must link it using the G++ driver, or using the option
-shared-libgcc, such that it is linked with the shared
libgcc.
-static-libasan
-static-libtsan
-static-liblsan
-static-libubsan
-static-libstdc++
-symbolic
-T
script-Xlinker
optionIf you want to pass an option that takes a separate argument, you must use -Xlinker twice, once for the option and once for the argument. For example, to pass -assert definitions, you must write -Xlinker -assert -Xlinker definitions. It does not work to write -Xlinker "-assert definitions", because this passes the entire string as a single argument, which is not what the linker expects.
When using the GNU linker, it is usually more convenient to pass
arguments to linker options using the option=value
syntax than as separate arguments. For example, you can specify
-Xlinker -Map=output.map rather than
-Xlinker -Map -Xlinker output.map. Other linkers may not support
this syntax for command-line options.
-Wl,
option-u
symbol-z
keyword[1] On some systems, ‘gcc -shared’ needs to build supplementary stub code for constructors to work. On multi-libbed systems, ‘gcc -shared’ must select the correct support libraries to link against. Failing to supply the correct flags may lead to subtle defects. Supplying them in cases where they are not necessary is innocuous.