Link against dynamic libraries. This is only meaningful on platforms for which shared libraries are supported. This option is normally the default on such platforms. The different variants of this option are for compatibility with various systems. You may use this option multiple times on the command line: it affects library searching for -l options which follow it. This causes the runtime linker to handle lookups in this object and its dependencies to be performed only inside the group.
Do not link against shared libraries. This option can be used with -shared. When creating a shared library, bind references to global symbols to the definition within the shared library, if any.
Normally, it is possible for a program linked against a shared library to override the definition within the shared library. When creating a shared library, bind references to global function symbols to the definition within the shared library, if any. Specify the name of a dynamic list file to the linker. The format of the dynamic list is the same as the version node without scope and node name.
Asks the linker not to check section addresses after they have been assigned to see if there are any overlaps. Normally the linker will perform this check, and if it finds any overlaps it will produce suitable error messages. The linker does know about, and does make allowances for sections in overlays. The default behaviour can be restored by using the command-line switch --check-sections.
Section overlap is not usually checked for relocatable links. You can force checking in that case by using the --check-sections option. The default behaviour can be restored with --no-copy-dt-needed-entries.
This option also has an effect on the resolution of symbols in dynamic libraries. With the default setting however the searching of dynamic libraries that follow it will stop with the dynamic library itself.
Output a cross reference table. If a linker map file is being generated, the cross reference table is printed to the map file. Otherwise, it is printed on the standard output. The format of the table is intentionally simple, so that it may be easily processed by a script if necessary. The symbols are printed out, sorted by name.
For each symbol, a list of file names is given. If the symbol is defined, the first file listed is the location of the definition. If the symbol is defined as a common value then any files where this happens appear next. Finally any files that reference the symbol are listed.
The CTF debuginfo format supports a section which encodes the names and types of variables found in the program which do not appear in any symbol table. These variables clearly cannot be looked up by address by conventional debuggers, so the space used for their types and names is usually wasted: the types are usually small but the names are often not.
The default behaviour can be restored with --no-ctf-variables. Put all types that do not have ambiguous definitions into the shared dictionary, where debuggers can easily access them, even if they only occur in one translation unit.
This is the default. Put only types that occur in multiple translation units into the shared dictionary: types with only one definition go into per-translation-unit dictionaries. Types with ambiguous definitions in multiple translation units always go into per-translation-unit dictionaries. This option inhibits the assignment of addresses to common symbols. This eliminates the unused duplicate space in the shared library, and also prevents any possible confusion over resolving to the wrong duplicate when there are many dynamic modules with specialized search paths for runtime symbol resolution.
This option causes the linker to place section group members like normal input sections, and to delete the section groups. Create a global symbol in the output file, containing the absolute address given by expression.
You may use this option as many times as necessary to define multiple symbols in the command line. If you need more elaborate expressions, consider using the linker command language from a script see Assignments. These options control whether to demangle symbol names in error messages and other output. Different compilers have different mangling styles. The optional demangling style argument can be used to choose an appropriate demangling style for your compiler.
These options may be used to override the default. Set the name of the dynamic linker. This is only meaningful when generating dynamically linked ELF executables. When producing an executable file, omit the request for a dynamic linker to be used at load-time.
This is only meaningful for ELF executables that contain dynamic relocations, and usually requires entry point code that is capable of processing these relocations. This option is similar to the --emit-relocs option except that the relocs are stored in a target-specific section. Do not allow multiple definitions with symbols included in filename invoked by -R or —just-symbols. Treat all warnings as errors.
The default behaviour can be restored with the option --no-fatal-warnings. If a successfully built fully linked output file does not have a. Enable garbage collection of unused input sections. It is ignored on targets that do not support this option. Note that garbage collection for COFF and PE format targets is supported, but the implementation is currently considered to be experimental. The section containing the entry symbol and all sections containing symbols undefined on the command-line will be kept, as will sections containing symbols referenced by dynamic objects.
Note that when building shared libraries, the linker must assume that any visible symbol is referenced. Once this initial set of sections has been determined, the linker recursively marks as used any section referenced by their relocations. List all sections removed by garbage collection. The listing is printed on stderr. This option is intended to be used for executables where unreferenced sections would otherwise be garbage collected regardless of the external visibility of contained symbols.
Note that this option has no effect when linking shared objects since it is already the default behaviour. This option is only supported for ELF format targets. Print the name of the default output format perhaps influenced by other command-line options. This is useful on embedded targets to have a quick view of amount of free memory.
The format of the output has one headline and one line per region. It is both human readable and easily parsable by tools. Here is an example of an output:. Print a link map to the file mapfile. See the description of the -M option, above. If mapfile is just the character - then the map will be written to stdout. Specifying a directory as mapfile causes the linker map to be written as a file inside the directory. Normally name of the file inside the directory is computed as the basename of the output file with.
This option tells ld to instead optimize for memory usage, by rereading the symbol tables as necessary. This may be required if ld runs out of memory space while linking a large executable. The switch --[no-]allow-shlib-undefined controls the behaviour for reporting unresolved references found in shared libraries being linked in. Normally when a symbol is defined multiple times, the linker will report a fatal error. These options allow multiple definitions and the first definition will be used.
Allows or disallows undefined symbols in shared libraries. This switch is similar to --no-undefined except that it determines the behaviour when the undefined symbols are in a shared library rather than a regular object file. It does not affect how undefined symbols in regular object files are handled.
The default behaviour is to report errors for any undefined symbols referenced in shared libraries if the linker is being used to create an executable, but to allow them if the linker is being used to create a shared library. The reasons for allowing undefined symbol references in shared libraries specified at link time are that:.
The BeOS kernel for example patches shared libraries at load time to select whichever function is most appropriate for the current architecture. This is used, for example, to dynamically select an appropriate memset function.
If this option is provided then the linker will invoke scriptname whenever an error is encountered. Currently however only two kinds of error are supported: missing symbols and missing libraries. The intention is that the script will provide suggestions to the user as to where the symbol or library might be found.
After the script has finished then the normal linker error message will be displayed. The availability of this option is controlled by a configure time switch, so it may not be present in specific implementations. Normally when a symbol has an undefined version, the linker will ignore it. This option disallows symbols with undefined version and a fatal error will be issued instead.
Normally ld will give an error if you try to link together input files that are mismatched for some reason, perhaps because they have been compiled for different processors or for different endiannesses. This option tells ld that it should silently permit such possible errors.
This option should only be used with care, in cases when you have taken some special action that ensures that the linker errors are inappropriate. Normally ld will give a warning if it finds an incompatible library during a library search. This option silences the warning. Retain the executable output file whenever it is still usable.
Normally, the linker will not produce an output file if it encounters errors during the link process; it exits without writing an output file when it issues any error whatsoever. Only search library directories explicitly specified on the command line. Library directories specified in linker scripts including linker scripts specified on the command line are ignored. Create an import library in file corresponding to the executable the linker is generating eg. Create a position independent executable.
This is currently only supported on ELF platforms. Position independent executables are similar to shared libraries in that they are relocated by the dynamic linker to the virtual address the OS chooses for them which can vary between invocations.
Like normal dynamically linked executables they can be executed and symbols defined in the executable cannot be overridden by shared libraries. An option with machine dependent effects.
This option is only supported on a few targets. See ld and Xtensa Processors. See ld and the 68HC11 and 68HC See ld and the Altera Nios II. On some platforms the --relax option performs target specific, global optimizations that become possible when the linker resolves addressing in the program, such as relaxing address modes, synthesizing new instructions, selecting shorter version of current instructions, and combining constant values.
On some platforms these link time global optimizations may make symbolic debugging of the resulting executable impossible. On platforms where the feature is not supported, both --relax and --no-relax are accepted, but ignored. Retain only the symbols listed in the file filename , discarding all others. This option is especially useful in environments such as VxWorks where a large global symbol table is accumulated gradually, to conserve run-time memory.
Add a directory to the runtime library search path. This is used when linking an ELF executable with shared objects. All -rpath arguments are concatenated and passed to the runtime linker, which uses them to locate shared objects at runtime. The -rpath option is also used when locating shared objects which are needed by shared objects explicitly included in the link; see the description of the -rpath-link option.
Searching -rpath in this way is only supported by native linkers and cross linkers which have been configured with the --with-sysroot option. The -rpath option may also be used on SunOS. By default, on SunOS, the linker will form a runtime search path out of all the -L options it is given.
If a -rpath option is used, the runtime search path will be formed exclusively using the -rpath options, ignoring the -L options. This can be useful when using gcc, which adds many -L options which may be on NFS mounted file systems. This happens when an ld -shared link includes a shared library as one of the input files. When the linker encounters such a dependency when doing a non-shared, non-relocatable link, it will automatically try to locate the required shared library and include it in the link, if it is not included explicitly.
In such a case, the -rpath-link option specifies the first set of directories to search. The -rpath-link option may specify a sequence of directory names either by specifying a list of names separated by colons, or by appearing multiple times. This option should be used with caution as it overrides the search path that may have been hard compiled into a shared library. In such a case it is possible to use unintentionally a different search path than the runtime linker would do.
If the required shared library is not found, the linker will issue a warning and continue with the link. 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. If libasan is available as a shared library, and the -static option is not used, then this links against the shared version of libasan.
The -static-libasan option directs the GCC driver to link libasan statically, without necessarily linking other libraries statically. If libtsan is available as a shared library, and the -static option is not used, then this links against the shared version of libtsan.
The -static-libtsan option directs the GCC driver to link libtsan statically, without necessarily linking other libraries statically. If liblsan is available as a shared library, and the -static option is not used, then this links against the shared version of liblsan.
The -static-liblsan option directs the GCC driver to link liblsan statically, without necessarily linking other libraries statically.
If libubsan is available as a shared library, and the -static option is not used, then this links against the shared version of libubsan. The -static-libubsan option directs the GCC driver to link libubsan statically, without necessarily linking other libraries statically. That is normally fine. Bind references to global symbols when building a shared object.
Warn about any unresolved references unless overridden by the link editor option -Xlinker -z -Xlinker defs. Only a few systems support this option. Use script as the linker script. This option is supported by most systems using the GNU linker. On some targets, such as bare-board targets without an operating system, the -T option may be required when linking to avoid references to undefined symbols.
Pass option as an option to the linker. You can use this to supply system-specific linker options that GCC does not recognize. If 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. Other linkers may not support this syntax for command-line options. If you do not include -o code. Just as the input to as might not be a executable program, the output of as might not be executable.
For example, a library is a set of functions that other programs can call, but does not have any entry point main function. It can also be that the compiled assembly code references functions that are in another binary file. For example, your program that calls a library, when compiled into machine code, does not have the actual instructions of those library calls. The tool that takes multiple binary files and links them together is ld , described below.
The linker. For example, when you have a library written in multiple source files, you typically compile each source file independently into an ELF object file, then link all of those files together into a larger ELF object file for the library.
When you compile a program that uses the library, you compile your program code into one or more object files, then link those against the library, producing a final executable.
The linker operates by resolving symbols. The name of each of your functions and global variables is a symbol. Symbols come in two forms: a definition that associates a name with its data e. Any use of the global a must be resolved to refer to this one copy of the variable. Similarly with a function named f. There will be one definition of f perhaps in a library. Every other place where you call the function f it generates an unresolved reference. It is the job of the linker to resolve all such references to use the one shared copy.
When the linker links your program, it sees that f is an unresolved symbol, sees where f is defined in the library, then fixes the binary code in your program so that when it calls f it jumps to where f exists. This takes two object files, links them together, and outputs the result as code. When you invoke GCC without the -c option, it typically runs ld as its last step.
For example,. The most commonly used options for ld are -l and -L. The -l option tells ld to link a library, which is basically just an object file. But libraries are typically stable code that you don't update often and are used by many programs, so they live in separate directories for that purpose e. Therefore, the directories list is different. Using built-in specs. You also can show the library search directories list by adding the verbose flag -v when linking.
For example: gcc -v foo. For example, ldd foo. Example output from my PC.
0コメント