.RB "[\|" \-embedded\-relocs "\|]"
.RB "[\|" \-E "\|]"
.RB "[\|" \-export\-dynamic "\|]"
-.RB "[\|" \-F "\|]"
+.RB "[\|" "\-f\ "\c
+.I name\c
+\&\|]
+.RB "[\|" "\-\-auxiliary\ "\c
+.I name\c
+\&\|]
.RB "[\|" "\-F\ "\c
-.I format\c
+.I name\c
+\&\|]
+.RB "[\|" "\-\-filter\ "\c
+.I name\c
\&\|]
.RB "[\|" "\-format\ "\c
.I input-format\c
.RB "[\|" \-G
.I size\c
\&\|]
+.RB "[\|" "\-h\ "\c
+.I name\c
+\&\|]
+.RB "[\|" "\-soname\ "\c
+.I name\c
+\&\|]
.RB "[\|" \-\-help "\|]"
.RB "[\|" \-i "\|]"
.RB "[\|" \-l\c
.I dlopen.
.TP
-.B \-F
+.BI "-f " "name"
.TP
-.BI "-F" "format"
-Some older linkers used this option throughout a compilation toolchain
-for specifying object-file format for both input and output object
-files. \c
-.B ld\c
-\&'s mechanisms (the \c
-.B \-b\c
-\& or \c
-.B \-format\c
-\& options
-for input files, the \c
-.B TARGET\c
-\& command in linker scripts for output
-files, the \c
-.B GNUTARGET\c
-\& environment variable) are more flexible, but
-but it accepts (and ignores) the \c
-.B \-F\c
-\& option flag for compatibility
-with scripts written to call the old linker.
+.BI "--auxiliary " "name"
+When creating an ELF shared object, set the internal DT_AUXILIARY field
+to the specified name. This tells the dynamic linker that the symbol
+table of the shared object should be used as an auxiliary filter on the
+symbol table of the shared object
+.I name.
+
+.TP
+.BI "-F " "name"
+.TP
+.BI "--filter " "name"
+When creating an ELF shared object, set the internal DT_FILTER field to
+the specified name. This tells the dynamic linker that the symbol table
+of the shared object should be used as a filter on the symbol table of
+the shared object
+.I name.
.TP
.BI "\-format " "input\-format"
.I size
under MIPS ECOFF. Ignored for other object file formats.
+.TP
+.BI "-h " "name"
+.TP
+.BI "-soname " "name"
+When creating an ELF shared object, set the internal DT_SONAME field to
+the specified name. When an executable is linked with a shared object
+which has a DT_SONAME field, then when the executable is run the dynamic
+linker will attempt to load the shared object specified by the DT_SONAME
+field rather than the using the file name given to the linker.
+
.TP
.B \-\-help
Print a summary of the command-line options on the standard output and exit.
symbols which are used by a dynamic object. This option is needed for
some uses of @code{dlopen}.
-@ifclear SingleFormat
+@kindex -f
+@kindex --auxiliary
+@item -f
+@itemx --auxiliary @var{name}
+When creating an ELF shared object, set the internal DT_AUXILIARY field
+to the specified name. This tells the dynamic linker that the symbol
+table of the shared object should be used as an auxiliary filter on the
+symbol table of the shared object @var{name}.
+
@kindex -F
-@item -F
-@itemx -F@var{format}
-Ignored. Some older linkers used this option throughout a compilation
+@kindex --filter
+@item -F @var{name}
+@itemx --filter @var{name}
+When creating an ELF shared object, set the internal DT_FILTER field to
+the specified name. This tells the dynamic linker that the symbol table
+of the shared object should be used as a filter on the symbol table of
+the shared object @var{name}.
+
+Some older linkers used the @code{-F} option throughout a compilation
toolchain for specifying object-file format for both input and output
-object files. The mechanisms @code{ld} uses for this purpose (the
-@samp{-b} or @samp{--format} options for input files, @samp{--oformat}
-option or the @code{TARGET} command in linker scripts for output files,
-the @code{GNUTARGET} environment variable) are more flexible, but
-@code{ld} accepts the @samp{-F} option for compatibility with scripts
-written to call the old linker.
-@end ifclear
+object files. The @sc{gnu} linker uses other mechanisms for this
+purpose: the @code{-b}, @code{--format}, @code{--oformat} options, the
+@code{TARGET} command in linker scripts, and the @code{GNUTARGET}
+environment variable. The @sc{gnu} linker will ignore the @code{-F}
+option when not creating an ELF shared object.
@kindex --force-exe-suffix
@item --force-exe-suffix
a patch is all we need. We might see problems with your patch and decide
to fix the problem another way, or we might not understand it at all.
-Sometimes with a program as complicated as @code{@value{AS}} it is very hard to
-construct an example that will make the program follow a certain path through
-the code. If you do not send us the example, we will not be able to construct
-one, so we will not be able to verify that the bug is fixed.
+Sometimes with a program as complicated as @code{ld} it is very hard to
+construct an example that will make the program follow a certain path
+through the code. If you do not send us the example, we will not be
+able to construct one, so we will not be able to verify that the bug is
+fixed.
And if we cannot understand what bug you are trying to fix, or why your
patch should be an improvement, we will not install it. A test case will