@code{now} marks the object with the non-lazy runtime binding.
@code{origin} marks the object may contain $ORIGIN.
@code{defs} disallows undefined symbols.
+@code{muldefs} allows multiple definitions.
@code{combreloc} combines multiple reloc sections and sorts them
to make dynamic symbol lookup caching possible.
@code{nocombreloc} disables multiple reloc sections combining.
are allowed and left to be resolved by the runtime loader. These options
disallows such undefined symbols.
+@kindex --allow-multiple-definition
+@kindex -z muldefs
+@item --allow-multiple-definition
+@itemx -z muldefs
+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.
+
@kindex --allow-shlib-undefined
@item --allow-shlib-undefined
Allow undefined symbols in shared objects even when --no-undefined is
I.E. dynamically select an appropriate memset function. Apparently it
is also normal for HPPA shared libraries to have undefined symbols.
+@kindex --no-undefined-version
+@item --no-undefined-version
+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.
+
@kindex --no-warn-mismatch
@item --no-warn-mismatch
Normally @command{ld} will give an error if you try to link together input
Specifies a list of symbols which should not be automatically
exported. The symbol names may be delimited by commas or colons.
+@kindex --exclude-libs
+@item --exclude-libs @var{lib},@var{lib},...
+Specifies a list of archive libraries from which symbols should not be automatically
+exported. The library names may be delimited by commas or colons. Specifying
+@code{--exclude-libs ALL} excludes symbols in all archive libraries from
+automatic export. Symbols explicitly listed in a .def file are still exported,
+regardless of this option.
+
@kindex --file-alignment
@item --file-alignment
Specify the file alignment. Sections in the file will always begin at
@cindex output file format in linker script
The @code{OUTPUT_FORMAT} command names the BFD format to use for the
output file (@pxref{BFD}). Using @code{OUTPUT_FORMAT(@var{bfdname})} is
-exactly like using @samp{-oformat @var{bfdname}} on the command line
+exactly like using @samp{--oformat @var{bfdname}} on the command line
(@pxref{Options,,Command Line Options}). If both are used, the command
line option takes precedence.
in the C source file. This renames the function @samp{original_foo} to
be an alias for @samp{foo} bound to the version node @samp{VERS_1.1}.
The @samp{local:} directive can be used to prevent the symbol
-@samp{original_foo} from being exported.
+@samp{original_foo} from being exported. A @samp{.symver} directive
+takes precedence over a version script.
The second GNU extension is to allow multiple versions of the same
function to appear in a given shared library. In this way you can make
@cindex round up location counter
@cindex align location counter
Return the location counter (@code{.}) aligned to the next @var{exp}
-boundary. @var{exp} must be an expression whose value is a power of
-two. This is equivalent to
-@smallexample
-(. + @var{exp} - 1) & ~(@var{exp} - 1)
-@end smallexample
-
+boundary.
@code{ALIGN} doesn't change the value of the location counter---it just
does arithmetic on it. Here is an example which aligns the output
@code{.data} section to the next @code{0x2000} byte boundary after the
Often people omit facts because they think they know what causes the
problem and assume that some details do not matter. Thus, you might
-assume that the name of a symbol you use in an example does not matter.
-Well, probably it does not, but one cannot be sure. Perhaps the bug is
-a stray memory reference which happens to fetch from the location where
-that name is stored in memory; perhaps, if the name were different, the
-contents of that location would fool the linker into doing the right
-thing despite the bug. Play it safe and give a specific, complete
-example. That is the easiest thing for you to do, and the most helpful.
-
-Keep in mind that the purpose of a bug report is to enable us to fix the bug if
-it is new to us. Therefore, always write your bug reports on the assumption
-that the bug has not been reported previously.
+assume that the name of a symbol you use in an example does not
+matter. Well, probably it does not, but one cannot be sure. Perhaps
+the bug is a stray memory reference which happens to fetch from the
+location where that name is stored in memory; perhaps, if the name
+were different, the contents of that location would fool the linker
+into doing the right thing despite the bug. Play it safe and give a
+specific, complete example. That is the easiest thing for you to do,
+and the most helpful.
+
+Keep in mind that the purpose of a bug report is to enable us to fix
+the bug if it is new to us. Therefore, always write your bug reports
+on the assumption that the bug has not been reported previously.
Sometimes people give a few sketchy facts and ask, ``Does this ring a
bell?'' Those bug reports are useless, and we urge everyone to
@item
A complete input file, or set of input files, that will reproduce the
-bug. It is generally most helpful to send the actual object files,
-uuencoded if necessary to get them through the mail system. Making them
-available for anonymous FTP is not as good, but may be the only
-reasonable choice for large object files.
+bug. It is generally most helpful to send the actual object files
+provided that they are reasonably small. Say no more than 10K. For
+bigger files you can either make them available by FTP or HTTP or else
+state that you are willing to send the object file(s) to whomever
+requests them. (Note - your email will be going to a mailing list, so
+we do not want to clog it up with large attachments). But small
+attachments are best.
If the source files were assembled using @code{gas} or compiled using
@code{gcc}, then it may be OK to send the source files rather than the
projects / deliverable / binutils-gdb.git / blobdiff