This was disabled as part of the migration away from the cygnus option
as that implied no-dependencies.
We currently have 1-to-1 updates enabled -- if you touch a .c file,
the corresponding .o file will be rebuilt. But if you touch a header
file, none of the files using that get rebuilt.
This was only ever used for i?86-pc-linux-gnu targets, but that's been
broken for years, and has since been dropped. So clean this up too.
This also deletes the funky objectlist logic since it only existed for
the libtool libraries. Since it was the only thing left in the small
Makefile.shared file, we can punt that too.
Now that we use AC_NO_EXECUTABLES, and we require a recent version of
autoconf, we don't need to define our own copies of these macros. So
switch to the standard AC_PROG_CC.
This logic was added to libc & libm to get it working again after some
reworks in the CPP handling, but now that that's settled, let's move
this to the common newlib configure logic. This will make it easier
to consolidate all the configure calls into the top-level newlib dir.
This does create a lot of noise in the generate scripts, but that's
because of the ordering of the calls, not because of correctness. We
will try to draw that back down in follow up commits as we modernize
the toolchain calls in here.
When using the top-level configure script but subdir Makefiles, the
newlib_basedir value gets a bit out of sync: it's relative to where
configure lives, not where the Makefile lives. Move the abs setting
from the top-level configure script into acinclude.m4 so we can rely
on it being available everywhere. Although this commit doesn't use
it anywhere, just lays the groundwork.
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.
The current newlib multilib logic is almost exactly the same as the
config/multi.m4, and the differences should be minor, so switch over
to that to delete custom logic on ourside.
Currently this is only enabled in the top-level as that's the only
place where it seemed to be used. But the libc/sys/phoenix/ dir
also uses this functionality, but fails to explicitly enable it.
Automake workedaround it, but generated warnings. Move the option
to NEWLIB_CONFIGURE so all dirs get it automatically iff they end
up using the option. If they don't use the option, there's no
difference to the generated code.
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.
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.
This is simply reflecting reality: all the subdirs in here are already
using automake-1.11.6, so making it a requirement will allow us to stop
suggesting we might support automake-1.9 or 1.10 (which I'm fairly sure
do not work today).
This is why only acinclude.m4 changes in this patch: the generated files
are exactly the same as the directives here are automake constraints,
not generated code logic.
The 'cygnus' option was removed from automake 1.13 in 2012, so the
presence of this option prevents that or a later version of automake
being used.
A check-list of the effects of '--cygnus' from the automake 1.12
documentation, and steps taken (where possible) to preserve those
effects (See also this thread [1] for discussion on that):
[1] https://lists.gnu.org/archive/html/bug-automake/2012-03/msg00048.html
1. The foreign strictness is implied.
Already present in AM_INIT_AUTOMAKE in newlib/acinclude.m4
2. The options no-installinfo, no-dependencies and no-dist are implied.
Already present in AM_INIT_AUTOMAKE in newlib/acinclude.m4
Future work: Remove no-dependencies and any explicit header dependencies,
and use automatic dependency tracking instead. Are there explicit rules
which are now redundant to removing no-installinfo and no-dist?
3. The macro AM_MAINTAINER_MODE is required.
Already present in newlib/acinclude.m4
Note that maintainer-mode is still disabled by default.
4. Info files are always created in the build directory, and not in the
source directory.
This appears to be an error in the automake documentation describing
'--cygnus' [2]. newlib's info files are generated in the source
directory, and no special steps are needed to keep doing that.
[2] https://lists.gnu.org/archive/html/bug-automake/2012-04/msg00028.html
5. texinfo.tex is not required if a Texinfo source file is specified.
(The assumption is that the file will be supplied, but in a place that
automake cannot find.)
This effect is overriden by an explicit setting of the TEXINFO_TEX
variable (the directory part of which is fed into texi2X via the
TEXINPUTS environment variable).
6. Certain tools will be searched for in the build tree as well as in the
user's PATH. These tools are runtest, expect, makeinfo and texi2dvi.
For obscure automake reasons, this effect of '--cygnus' is not active
for makeinfo in newlib's configury.
However, there appears to be top-level configury which selects in-tree
runtest, expect and makeinfo, if present. So, if that works as it
appears, this effect is preserved. If not, this may cause problem if
anyone is building those tools in-tree.
This effect is not preserved for texi2dvi. This may cause problems if
anyone is building texinfo in-tree.
If needed, explicit checks for those tools looking in places relative to
$(top_srcdir)/../ as well as in PATH could be added.
7. The check target doesn't depend on all.
This effect is not preseved. The check target now depends on the all
target.
This concern seems somewhat academic given the current state of the
testsuite.
Also note that this doesn't touch libgloss.
Add all the effects of 'cygnus' for which there exists an explicit way
to request that behaviour:
* Implied foreign strictness and options no-installinfo, no-dependencies
and no-dist are added to AM_INIT_AUTOMAKE in newlib/acinclude.m4.
* macro AM_MAINTAINER_MODE is added to newlib/acinclude.m4.
* For the implied TEXINFO_TEX of '$(top_srcdir)/../texinfo/texinfo.tex',
an explicit TEXINFO_TEX is always relative to $(srcdir), so write the
same pathname in that form.
This is to prepare for the removal of the automake option '--cygnus'.
Use AM_SILENT_RULES, to enable automake silent rules (by default), if we
are using a version of automake which supports it (>=1.11).
Silent rules can be disabled by configuring with '--disable-silent-rules',
or invoking 'make V=1'.
For ease of reviewing, this patch doesn't contain configure and
Makefile.in regeneration.
Future work: There are a few compilations which are not silenced by
this, as they use custom rules.
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>
* configure.host: Add noinclude variable to allow specification
of header files to remove from installation.
* acinclude.m4: Provide NO_INCLUDE_LIST variable based on
noinclude variable in configure.host.
* configure: Regenerated.
* Makefile.am: Remove all header files in NO_INCLUDE_LIST.
* Makefile.in: Regenerated.