Convert all the libm/ subdir makes into the top-level Makefile. This
allows us to build all of libm from the top Makefile without using any
recursive make calls. This is faster and avoids the funky lib.a logic
where we unpack subdir archives to repack into a single libm.a. The
machine override logic is maintained though by way of Makefile include
ordering, and source file accumulation in libm_a_SOURCES.
One thing to note is that this will require GNU Make because of:
libm_a_CFLAGS = ... $(libm_a_CFLAGS_$(subst /,_,$(@D)))
This was the only way I could find to supporting per-dir compiler
settings, and I couldn't find a POSIX compatible way of transforming
the variable content. I don't think this is a big deal as other
Makefiles in the tree are using GNU Make-specific syntax, but I call
this out as it's the only one so far in the new automake code that
I've been writing.
Automake doesn't provide precise control over the output object names
(by design). This is fine by default as we get consistent names in all
the subdirs: libm_a-<source>.o. But this relies on using the same set
of compiler flags for all objects. We currently compile libm/common/
with different optimizations than the rest.
If we want to compile objects differently, we can create an intermediate
archive with the subset of objects with unique flags, and then add those
objects to the main archive. But Automake will use a different prefix
for the objects, and thus we can't rely on ordering to override.
But if we leverage $@, we can turn Automake's CFLAGS into a multiplex
on a per-dir (and even per-file if we wanted) basis. Unfortunately,
since $@ contains /, Automake complains it's an invalid name. While
GNU Make supports this, it's a POSIX extension, so Automake flags it.
Using $(subst) avoids the Automake warning to get a POSIX compliant
name, albeit with a GNU Make extension.
Make this a separate target from libc so that we can migrate libc over
to automake more easily. Having it integrated into the libc target is
difficult to handle when using automake rules which expect a one-to-one
mapping between names & inputs.
When migrating the manual to the top-level, the include order was
sorted by name of the subdir. But this changed the chapter order
of the manual in the process. Change the sorting back to match
existing chapters and update the comments to explain.
This kills off the last configure script under libm/ and folds it
into the top newlib configure script. The vast majority of logic
was already in the top configure script, so move the little that
is left into a libm/acinclude.m4 file.
Make sure we depend on the right name of mkdoc all the time, and that
the rules that need it (e.g. .def files) depend on it.
Reported-by: Jon Turney <jon.turney@dronecode.org.uk>
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 allows building the libc & libm pages in parallel, and drops
the duplication in the subdirs with the chew/chapter settings.
The unused rules in Makefile.shared are left in place to minimize
noise in the change.
This doesn't migrate all the docs, just the libc's manual (pdf/info).
This is to show the basic form of migrating the chew files.
For subdirs that didn't have any docs, I've stripped their settings
for clarity. If someone wanted to suddenly add docs, they can add
the corresponding Makefile.inc files easily.
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.
We use the common config-ml.in for configure, so switch the makefile
over to the common multilib.am. It's almost exactly the same code,
but there are two differences:
* Common code hooks install-exec-local for install-multi, but newlib
doesn't currently install any executables, so that doesn't fire.
Newlib already has install-data-local that inlined install-multi,
so switch that to the common install-multi.
* Common code doesn't provide a check-multi at all. Keep ours for
now. Some day common code might get it. Or not. Who knows.
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.
Now that newlib.hin has been brought up to date and all of its defines
are produced by configure, we can switch it to using autoheader without
manual editing. This relies on a few pieces:
* Moving the header & footer into configure.ac via AH_TOP & AH_BOTTOM.
* Running a post-process step on newlib.h to delete all the defines we
didn't export ourselves. Basically, anything without a _ prefix.
This will leave behind some spurious comments in newlib.h related to
the defines we filtered out, but should be harmless, so it's probably
not worth the effort to construct a more complicated sed expression to
also strip those out.
The list of iconv to/from defines is hand maintained in newlib.hin.
Lets leverage mkdeps.pl to generate this list automatically from the
list of known encodings. The newlib.hin list is up-to-date, so the
list in iconv.m4 matches the list already generated.
This will make it easier to move newlib.h to use autoheader directly.
We only want the newlib version defines in our hand curated version
file, _newlib_version.h, not in the template header, newlib.h, so
using AC_DEFINE doesn't make much sense.
The acconfig.h header was used to run autoheader and then manually
sync the output into newlib.hin. Based on how the files have fallen
out of sync (with newlib.hin having many more templates), this has
not been run in a long time, and attempts to do so now would break
newlib.hin.
Further, if you try to run autoheader now, it will automatically
replace _newlib_version.hin since it's the first entry in the call
to AC_CONFIG_HEADERS.
So let's throw away acconfig.h entirely. It only had 2 slightly
better comments, and the rest were either worse, missing, or stale.
This has the side benefit of avoiding autoheader warning about the
deprecated use of acconfig.h since newer autoconf only wants macro
calls in configure.ac.
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.
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.
- Currently, printf("%La\n", 1e1000L) crashes with segv due to lack
of frexpl() function. With this patch, frexpl() function has been
implemented in libm to solve this issue.
Addresses: https://sourceware.org/pipermail/newlib/2021/018718.html
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.
previous commit 4c90db7bc8 introduced
a compile time error because libm/common/s_infconst.c used the remove
__fmath, __dmath, and __ldmath union types.
Since this is very old, and unused for a very long time, just drop the
file and thus the __infinity constants entirely.
Exception: Cygwin exports __infinity from the beginning. There's a very,
VERY low probability that any existing executable or lib still uses this
constant, but we just keep it in for backward compat, nevertheless.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
https://sourceware.org/ml/newlib/2016/msg01139.htmlhttps://gcc.gnu.org/ml/gcc/2016-12/msg00010.html
There is no change if libtool is used.
Some run-time support libraries provided by GCC (e.g. libgomp) use
configure checks to detect certain features, e.g. availability of
thread-local storage. The configure script generates a test program and
tries to compile and link it. It should use target libraries and
startfiles of the build tree if available and not random ones from the
installation prefix for this procedure. The search directories
specified by -B are a bit special, see for_each_path() in gcc.c of the
GCC sources. First a search is performed on all search paths with the
multilib directory appended (if desired), then a second search is
performed on demand with the base directory only. For each multilib
there is a "newlib" subdirectory. This directory is specified by a -B
option for the support libraries. In order to find the newlib artifacts
(ctr0.o, libc.a, libg.a and libm.a) they must be located in a proper
multilib subdirectory withing the build directory.
Signed-off-by: Sebastian Huber <sebastian.huber@embedded-brains.de>
Ensure the Python Lex/Yacc (PLY) cache used by makedocbook is initialized
before it is used by parallelizable rules to make the DocBook XML, as it
appears that these can collide in cache generation, leading to errors.
Signed-off-by: Jon Turney <jon.turney@dronecode.org.uk>
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.in: Comment out the --enable-newlib-fp-hw option
as the mathfp library is inaccurate and should not be used.
* Makefile.am: Add comment regarding the mathfp directory.
* configure: Regenerated.
* Makefile.in: Ditto.
* libm/mathfp/README: New file that details why the mathfp
directory is not used.
* 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.
Mike Frysinger
Jon Turney
Takashi Yano
Corinna Vinschen
Thomas Wolff
Jeff Johnston
Yaakov Selkowitz
Pieter du Preez