For some reason, these targets are missing although others from the
same family are present. This looks like an oversight.
This enables calling 'make install-dvi' from the top-level build
directory.
Adds two new external authors to etc/update-copyright.py to cover
bfd/ax_tls.m4, and adds gprofng to dirs handled automatically, then
updates copyright messages as follows:
1) Update cgen/utils.scm emitted copyrights.
2) Run "etc/update-copyright.py --this-year" with an extra external
author I haven't committed, 'Kalray SA.', to cover gas testsuite
files (which should have their copyright message removed).
3) Build with --enable-maintainer-mode --enable-cgen-maint=yes.
4) Check out */po/*.pot which we don't update frequently.
This regenerates config files changed by the previous 44 commits.
Note that subject lines in these commits mostly match the gcc git
originating commit.
The newer update-copyright.py fixes file encoding too, removing cr/lf
on binutils/bfdtest2.c and ld/testsuite/ld-cygwin/exe-export.exp, and
embedded cr in binutils/testsuite/binutils-all/ar.exp string match.
Some components of GNU Binutils will pass "-Wstack-usage=262144" when
"GCC >= 5.0" is detected. However, Clang does not support "-Wstack-usage",
despite that related configuration part in bfd/warning.m4 handles the latest
Clang (15.0.0 as of this writing) as "GCC >= 5.0".
The option "-Wstack-usage" was ignored when the first version of Clang is
released but even this "ignoring" behavior is removed before Clang 4.0.0.
So, if we give Clang "-Wstack-usage=262144", it generates a warning, making
the build failure.
This commit checks "__clang__" macro to prevent adding the option if the
compiler is identified as Clang.
bfd/ChangeLog:
* warning.m4: Stop appending "-Wstack-usage=262144" option when
compiled with Clang.
* configure: Regenerate.
binutils/ChangeLog:
* configure: Regenerate.
gas/ChangeLog:
* configure: Regenerate.
gold/ChangeLog:
* configure: Regenerate.
gprof/ChangeLog:
* configure: Regenerate.
ld/ChangeLog:
* configure: Regenerate.
opcodes/ChangeLog:
* configure: Regenerate.
BFD_VMA_FMT can't be used in format strings that need to be
translated, because the translation won't work when the type of
bfd_vma differs from the machine used to compile .pot files. We've
known about this for a long time, but patches slip through review.
So just get rid of BFD_VMA_FMT, instead using the appropriate PRId64,
PRIu64, PRIx64 or PRIo64 and SCN variants for scanf. The patch is
mostly mechanical, the only thing requiring any thought is casts
needed to preserve PRId64 output from bfd_vma values, or to preserve
one of the unsigned output formats from bfd_signed_vma values.
Until we update the recommended versions of autoconf/automake, files
should be regenerated with automake-1.15.1 and autoconf-2.69. That's
not because we think those versions are golden, and newer versions are
bad. It's simply because maintainers want to be able to update
configury files without trouble, and if someone regenerates files with
automake-1.16.5 then --enable-maintainer-mode builds will hit errors:
checking that generated files are newer than configure... configure.ac:26: error: version mismatch. This is Automake 1.15.1,
configure.ac:26: but the definition used by this AM_INIT_AUTOMAKE
configure.ac:26: comes from Automake 1.16.5. You should recreate
configure.ac:26: aclocal.m4 with aclocal and run automake again.
WARNING: 'automake-1.15' is probably too old.
Correcting this requires regenerating the files by hand.
Requiring C99 means that uses of bfd_uint64_t can be replaced with
uint64_t, and similarly for bfd_int64_t, BFD_HOST_U_64_BIT, and
BFD_HOST_64_BIT. This patch does that, removes #ifdef BFD_HOST_*
and tidies a few places that print 64-bit values.
My previous nm patch handled all cases but one -- if the user set NM in
the environment to a path which contained an option, libtool's nm
detection tries to run nm against a copy of nm with the options in it:
e.g. if NM was set to "nm --blargle", and nm was found in /usr/bin, the
test would try to run "/usr/bin/nm --blargle /usr/bin/nm --blargle".
This is unlikely to be desirable: in this case we should run
"/usr/bin/nm --blargle /usr/bin/nm".
Furthermore, as part of this nm has to detect when the passed-in $NM
contains a path, and in that case avoid doing a path search itself.
This too was thrown off if an option contained something that looked
like a path, e.g. NM="nm -B../prev-gcc"; libtool then tries to run
"nm -B../prev-gcc nm" which rarely works well (and indeed it looks
to see whether that nm exists, finds it doesn't, and wrongly concludes
that nm -p or whatever does not work).
Fix all of these by clipping all options (defined as everything
including and after the first " -") before deciding whether nm
contains a path (but not using the clipped value for anything else),
and then removing all options from the path-modified nm before
looking to see whether that nm existed.
NM=my-nm now does a path search and runs e.g.
/usr/bin/my-nm -B /usr/bin/my-nm
NM=/usr/bin/my-nm now avoids a path search and runs e.g.
/usr/bin/my-nm -B /usr/bin/my-nm
NM="my-nm -p../wombat" now does a path search and runs e.g.
/usr/bin/my-nm -p../wombat -B /usr/bin/my-nm
NM="../prev-binutils/new-nm -B../prev-gcc" now avoids a path search:
../prev-binutils/my-nm -B../prev-gcc -B ../prev-binutils/my-nm
This seems to be all combinations, including those used by GCC bootstrap
(which, before this commit, fails to bootstrap when configured
--with-build-config=bootstrap-lto, because the lto plugin is now using
--export-symbols-regex, which requires libtool to find a working nm,
while also using -B../prev-gcc to point at the lto plugin associated
with the GCC just built.)
Regenerate all affected configure scripts.
* libtool.m4 (LT_PATH_NM): Handle user-specified NM with
options, including options containing paths.
