It's unclear why this was added originally, but assuming it was needed
20 years ago, it shouldn't be explicitly required nowadays. Current
versions of autotools already take care of exporting LDFLAGS to the
Makefile as needed (things are actually getting linked). That's why
the configure diffs show LDFLAGS still here, but shifted to a diff
place in the output list. A few dirs stop exporting LDFLAGS, but
that's because they don't do any linking, only compiling, so it's
correct.
As for the use of $ldflags instead of the standard $LDFLAGS, I can't
really explain that at all. Just use the right name so users don't
have to dig into why their setting isn't respected, and then use a
non-standard name instead. Adjust the testsuite to match.
Now that we require a recent version of autoconf, we can rely on this
macro working. We shift the call in configure.ac down a little to
help keep the generated diff minimal -- there should be no functional
difference otherwise. This is because the autoconf macros will call
a bunch of standard toolchain macros first, and arguably the current
code is incorrect in how it does its testing.
Since AM_INIT_AUTOMAKE calls AC_PROG_AWK, and some configure.ac
scripts call it too, we end up testing for awk multiple times. If
we change NEWLIB_CONFIGURE to require the macro instead, then it
makes sure it's always expanded, but only once.
While we're here, do the same thing with AC_PROG_INSTALL since it
is also called by AM_INIT_AUTOMAKE, although it doesn't currently
result in duplicate configure checks.
The AC_LIBTOOL_WIN32_DLL macro has been deprecated for a while and code
should call LT_INIT with win32-dll instead. Update the calls to match.
The generated code is noisy not because of substantial differences, but
because the order of some macros change (i.e. instead of calling AS and
then CC, CC is called first and then AS).
This matches what the other GNU toolchain projects have done already.
The generated diff in practice isn't terribly large. This will allow
more use of subdir local.mk includes due to fixes & improvements that
came after the 1.11 release series.
The newlib & libgloss dirs are already generated using autoconf-2.69.
To avoid merging new code and/or accidental regeneration using diff
versions, leverage config/override.m4 to pin to 2.69 exactly. This
matches what gcc/binutils/gdb are already doing.
The README file already says to use autoconf-2.69.
To accomplish this, it's just as simple as adding -I flags to the
top-level config/ dir when running aclocal. This is because the
override.m4 file overrides AC_INIT to first require the specific
autoconf version before calling the real AC_INIT.
Libtool needs to get BSD-format (or MS-format) output out of the system
nm, so that it can scan generated object files for symbol names for
-export-symbols-regex support. Some nms need specific flags to turn on
BSD-formatted output, so libtool checks for this in its AC_PATH_NM.
Unfortunately the code to do this has a pair of interlocking flaws:
- it runs the test by doing an nm of /dev/null. Some platforms
reasonably refuse to do an nm on a device file, but before now this
has only been worked around by assuming that the error message has a
specific textual form emitted by Tru64 nm, and that getting this
error means this is Tru64 nm and that nm -B would work to produce
BSD-format output, even though the test never actually got anything
but an error message out of nm -B. This is fixable by nm'ing *nm
itself* (since we necessarily have a path to it).
- the test is entirely skipped if NM is set in the environment, on the
grounds that the user has overridden the test: but the user cannot
reasonably be expected to know that libtool wants not only nm but
also flags forcing BSD-format output. Worse yet, one such "user" is
the top-level Cygnus configure script, which neither tests for
nor specifies any BSD-format flags. So platforms needing BSD-format
flags always fail to set them when run in a Cygnus tree, breaking
-export-symbols-regex on such platforms. Libtool also needs to
augment $LD on some platforms, but this is done unconditionally,
augmenting whatever the user specified: the nm check should do the
same.
One wrinkle: if the user has overridden $NM, a path might have been
provided: so we use the user-specified path if there was one, and
otherwise do the path search as usual. (If the nm specified doesn't
work, this might lead to a few extra pointless path searches -- but
the test is going to fail anyway, so that's not a problem.)
(Tested with NM unset, and set to nm, /usr/bin/nm, my-nm where my-nm is a
symlink to /usr/bin/nm on the PATH, and /not-on-the-path/my-nm where
*that* is a symlink to /usr/bin/nm.)
ChangeLog
2021-09-27 Nick Alcock <nick.alcock@oracle.com>
PR libctf/27967
* libtool.m4 (LT_PATH_NM): Try BSDization flags with a user-provided
NM, if there is one. Run nm on itself, not on /dev/null, to avoid
errors from nms that refuse to work on non-regular files. Remove
other workarounds for this problem. Strip out blank lines from the
nm output.
This reports common symbols like GNU nm, via a type code of 'C'.
ChangeLog
2021-09-27 Nick Alcock <nick.alcock@oracle.com>
PR libctf/27967
* libtool.m4 (lt_cv_sys_global_symbol_pipe): Augment symcode for
Solaris 11.
AR from older binutils doesn't work with --plugin and rc:
[hjl@gnu-cfl-2 bin]$ touch foo.c
[hjl@gnu-cfl-2 bin]$ ar --plugin /usr/libexec/gcc/x86_64-redhat-linux/10/liblto_plugin.so rc libfoo.a foo.c
[hjl@gnu-cfl-2 bin]$ ./ar --plugin /usr/libexec/gcc/x86_64-redhat-linux/10/liblto_plugin.so rc libfoo.a foo.c
./ar: no operation specified
[hjl@gnu-cfl-2 bin]$ ./ar --version
GNU ar (Linux/GNU Binutils) 2.29.51.0.1.20180112
Copyright (C) 2018 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) any later version.
This program has absolutely no warranty.
[hjl@gnu-cfl-2 bin]$
Check if AR works with --plugin and rc before passing --plugin to AR and
RANLIB.
PR ld/27173
* configure: Regenerated.
* libtool.m4 (_LT_CMD_OLD_ARCHIVE): Check if AR works with
--plugin and rc before enabling --plugin.
config/
PR ld/27173
* gcc-plugin.m4 (GCC_PLUGIN_OPTION): Check if AR works with
--plugin and rc before enabling --plugin.
libiberty/
PR ld/27173
* configure: Regenerated.
zlib/
PR ld/27173
* configure: Regenerated.
So far the build mechanism in newlib only allowed to either define
machine-specific headers, or headers shared between all machines.
In some cases, architectures are sufficiently alike to share header
files between them, but not with other architectures. A good example
is ix86 vs. x86_64, which share certain traits with each other, but
not with other architectures.
Introduce a new configure variable called "shared_machine_dir". This
dir can then be used for headers shared between architectures.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
- From: Cesar Philippidis <cesar@codesourcery.com>
Date: Tue, 10 Apr 2018 14:43:42 -0700
Subject: [PATCH] nvptx port
This port adds support for Nvidia GPU's, which are primarily used as
offload accelerators in OpenACC and OpenMP.
Currently, the newlib version information needs to be updated in two places:
- newlib/acinclude.m4
- newlib/libc/include/sys/features.h
The goal of this patch is to:
- supply a single location for defining the newlib version
information: newlib/acinclude.m4
- define __NEWLIB__, __NEWLIB_MINOR__ and __NEWLIB_PATCHLEVEL__
This is in line with what gcc does for its version macros. See:
https://gcc.gnu.org/onlinedocs/cpp/Common-Predefined-Macros.html
This patch moves the definition of the _NEWLIB_VERSION, __NEWLIB__
and __NEWLIB_MINOR__ macros from newlib/libc/include/sys/features.h,
to the newly generated newlib/_newlib_version.h file. Additionally,
the __NEWLIB_PATCHLEVEL__ macro was created, for completeness.
In order to stay backwards compatible, newlib/_newlib_version.h gets
included by newlib/newlib.h and newlib/libc/include/sys/features.h.
Note: This patch does _not_ include the modifications to the following
files, as these should all be generated any way.
*Makefile.in,
*aclocal.m4,
*configure
stamp-* files
Signed-off-by: Pieter du Preez <pdupreez@gmail.com>