X-Git-Url: http://git.efficios.com/?a=blobdiff_plain;f=binutils%2FREADME;h=8b613fa42ebb3a51d2a2a9480f99d28486e7b874;hb=1d29ab86cb5145cac5045c1a4113d8b8fbd4d9c6;hp=6633792d87b350cc9d08b30a66e8bf4c75154467;hpb=effb06016a39cd7476eac77bdc94a09384acbdd3;p=deliverable%2Fbinutils-gdb.git diff --git a/binutils/README b/binutils/README index 6633792d87..8b613fa42e 100644 --- a/binutils/README +++ b/binutils/README @@ -13,12 +13,21 @@ There are README and NEWS files in most of the program sub-directories 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. @@ -48,7 +57,7 @@ By default, the binutils will be configured to support the system on 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, @@ -64,7 +73,7 @@ On 32-bit hosts though, this support will be restricted to 32-bit 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 @@ -79,10 +88,33 @@ binaries, you may have to set an environment variable, normally 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 ==================== @@ -100,7 +132,7 @@ ${MAKE} $* all-bfd cd binutils MAKE="${MAKE_PROG}" export MAKE -${MAKE} $* ar_DEPENDENCIES= ar_LDADD='../bfd/*.o `cat ../libiberty/required-list ../libiberty/needed-list | sed -e "s,\([^ ][^ ]*\),../libiberty/\1,g"` `if test -f ../intl/gettext.o; then echo '../intl/*.o'; fi`' ar +${MAKE} $* ar_DEPENDENCIES= ar_LDADD='../bfd/*.o ../libiberty/*.o `if test -f ../intl/gettext.o; then echo '../intl/*.o'; fi`' ar This script will build an ar program in binutils/ar. Move binutils/ar into a directory on your PATH. After doing this, you can run make as @@ -110,7 +142,7 @@ the ranlib program in order to build the distribution. 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. @@ -127,9 +159,66 @@ Send bug reports and patches to: 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 === @@ -202,3 +291,9 @@ unneeded objects and libraries: If you have any problems or questions about the binutils on VMS, feel free to mail me at kkaempf@rmi.de. + +Copyright (C) 2012-2019 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.