which give more information about those specific programs.
+Copyright Notices
+=================
+
+Copyright years on binutils source files may be listed using range
+notation, e.g., 1991-2012, indicating that every year in the range,
+inclusive, is a copyrightable year that could otherwise be listed
+individually.
+
+
Unpacking and Installation -- quick overview
============================================
When you unpack the binutils archive file, you will get a directory
called something like `binutils-XXX', where XXX is the number of the
-release. (Probably 2.12 or higher). This directory contains
+release. (Probably 2.13 or higher). This directory contains
various files and sub-directories. Most of the files in the top
directory are for information and for configuration. The actual
source code is in sub-directories.
which they are built. When doing cross development, use the --target
configure option to specify a different target, eg:
- ./configure --target=foo-elf
+ ./configure --target=foo-elf
The --enable-targets option adds support for more binary file formats
besides the default. List them as the argument to --enable-targets,
target unless the --enable-64-bit-bfd option is also used:
./configure --enable-64-bit-bfd --enable-targets=all
-
+
You can also specify the --enable-shared option when you run
configure. This will build the BFD and opcodes libraries as shared
libraries. You can use arguments with the --enable-shared option to
LD_LIBRARY_PATH, so that the system can find the installed libbfd
shared library.
+On hosts that support shared system libraries the binutils will be
+linked against them. If you have static versions of the system
+libraries installed as well and you wish to create static binaries
+instead then use the LDFLAGS environment variable, like this:
+
+ ../binutils-XXX/configure LDFLAGS="--static" [more options]
+
+Note: the two dashes are important. The binutils make use of the
+libtool script which has a special interpretation of "-static" when it
+is in the LDFLAGS environment variable.
+
To build under openVMS/AXP, see the file makefile.vms in the top level
directory.
+Native Language Support
+=======================
+
+By default Native Language Support will be enabled for binutils. On
+some systems however this support is not present and can lead to error
+messages such as "undefined reference to `libintl_gettext'" when
+building there tools. If that happens the NLS support can be disabled
+by adding the --disable-nls switch to the configure line like this:
+
+ ../binutils-XXX/configure --disable-nls
+
+
If you don't have ar
====================
Porting
=======
-Binutils-2.12 supports many different architectures, but there
+Binutils-2.13 supports many different architectures, but there
are many more not supported, including some that were supported
by earlier versions. We are hoping for volunteers to improve this
situation.
bug-binutils@gnu.org.
+Please include the following in bug reports:
+
+- A description of exactly what went wrong, and exactly what should have
+ happened instead.
+
+- The configuration name(s) given to the "configure" script. The
+ "config.status" file should have this information. This is assuming
+ you built binutils yourself. If you didn't build binutils youself,
+ then we need information regarding your machine and operating system,
+ and it may be more appropriate to report bugs to wherever you obtained
+ binutils.
+
+- The options given to the tool (gas, objcopy, ld etc.) at run time.
+
+- The actual input file that caused the problem.
+
Always mention the version number you are running; this is printed by
running any of the binutils with the --version option. We appreciate
-reports about bugs, but we do not promise to fix them.
+reports about bugs, but we do not promise to fix them, particularly so
+when the bug report is against an old version. If you are able, please
+consider building the latest tools from git to check that your bug has
+not already been fixed.
+
+When reporting problems about gas and ld, it's useful to provide a
+testcase that triggers the problem. In the case of a gas problem, we
+want input files to gas and command line switches used. The inputs to
+gas are _NOT_ .c or .i files, but rather .s files. If your original
+source was a C program, you can generate the .s file and see the command
+line options by passing -v -save-temps to gcc in addition to all the
+usual options you use. The reason we don't want C files is that we
+might not have a C compiler around for the target you use. While it
+might be possible to build a compiler, that takes considerable time and
+disk space, and we might not end up with exactly the same compiler you
+use.
+
+In the case of a ld problem, the input files are .o, .a and .so files,
+and possibly a linker script specified with -T. Again, when using gcc
+to link, you can see these files by adding options to the gcc command
+line. Use -v -save-temps -Wl,-t, except that on targets that use gcc's
+collect2, you would add -v -save-temps -Wl,-t,-debug. The -t option
+tells ld to print all files and libraries used, so that, for example,
+you can associate -lc on the ld command line with the actual libc used.
+Note that your simple two line C program to trigger a problem typically
+expands into several megabytes of objects by the time you include
+libraries.
+
+It is antisocial to post megabyte sized attachments to mailing lists, so
+please put large testcases somewhere on an ftp or web site so that only
+interested developers need to download them, or offer to email them on
+request. Better still, try to reduce the testcase, for example, try to
+develop a ld testcase that doesn't use system libraries. However,
+please be sure it is a complete testcase and that it really does
+demonstrate the problem. Also, don't bother paring it down if that will
+cause large delays in filing the bug report.
+
+If you expect to be contributing a large number of test cases, it would
+be helpful if you would look at the test suite included in the release
+(based on the Deja Gnu testing framework, available from the usual ftp
+sites) and write test cases to fit into that framework. This is
+certainly not required.
VMS
===
If you have any problems or questions about the binutils on VMS, feel
free to mail me at kkaempf@rmi.de.
+\f
+Copyright (C) 2012-2020 Free Software Foundation, Inc.
+
+Copying and distribution of this file, with or without modification,
+are permitted in any medium without royalty provided the copyright
+notice and this notice are preserved.
projects / deliverable / binutils-gdb.git / blobdiff