From: Alan Modra Date: Tue, 6 Apr 2021 04:12:18 +0000 (+0930) Subject: C99 NEWS and README X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=4db29512ce5616e90a9cdbc4daa852589b7357c0;p=binutils-gdb.git C99 NEWS and README * NEWS: Mention C99 requirement. * README: Likewise. Modernise examples and "Reporting bugs". --- diff --git a/binutils/ChangeLog b/binutils/ChangeLog index bdab7f909f1..13fa6d2d401 100644 --- a/binutils/ChangeLog +++ b/binutils/ChangeLog @@ -1,3 +1,8 @@ +2021-04-06 Alan Modra + + * NEWS: Mention C99 requirement. + * README: Likewise. Modernise examples and "Reporting bugs". + 2021-04-05 Alan Modra * configure.ac: Assume long long is available. Don't test for diff --git a/binutils/NEWS b/binutils/NEWS index c035f522e3f..c5b5f4f5952 100644 --- a/binutils/NEWS +++ b/binutils/NEWS @@ -1,5 +1,7 @@ -*- text -*- +* Binutils now requires a C99 compiler and library to build. + * A new format has been added to the nm program. Specifying --format=just-symbols (or just using -j) will tell the program to only display symbol names and nothing else. diff --git a/binutils/README b/binutils/README index 666260dc98d..aeae1924aae 100644 --- a/binutils/README +++ b/binutils/README @@ -17,7 +17,7 @@ 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, +notation, e.g., 1991-2021, indicating that every year in the range, inclusive, is a copyrightable year that could otherwise be listed individually. @@ -27,12 +27,13 @@ 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.13 or higher). This directory contains +release. (Probably 2.36 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. -To build binutils, you can just do: +To build binutils you will need a C99 compliant compiler and library. +You can just do: cd binutils-XXX ./configure [options] @@ -57,13 +58,13 @@ 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=powerpc64le-linux The --enable-targets option adds support for more binary file formats besides the default. List them as the argument to --enable-targets, separated by commas. For example: - ./configure --enable-targets=sun3,rs6000-aix,decstation + ./configure --enable-targets=powerpc-linux,rs6000-aix The name 'all' compiles in support for all valid BFD targets: @@ -142,7 +143,7 @@ the ranlib program in order to build the distribution. Porting ======= -Binutils-2.13 supports many different architectures, but there +Binutils-2.36 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. @@ -155,9 +156,9 @@ with gdb-5.x) may also be of help. Reporting bugs ============== -Send bug reports and patches to: +Please report bugs via - bug-binutils@gnu.org. + https://sourceware.org/bugzilla/enter_bug.cgi?product=binutils Please include the following in bug reports: @@ -205,14 +206,14 @@ 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. +There is a limit to the size of attachments accepted by bugzilla. If +compressing your testcase does not result in an acceptable size tar or +zip file, please put large testcases somewhere on an ftp or web site. +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