Remove the pointer indirection through the read-only _global_impure_ptr and
directly use a externally visible _impure_data object of type struct _reent.
This enables the static initialization of global data structures in a follow up
patch. In addition, we get rid of a machine-specific file.
This code has not been updated since 2016, and it looks like it has
rotted quite a bit since. It does not build against the current set
of phoenix sources -- I had to hack both the kernel headers and the
newlib headers up to get it to build, and I still have no idea if it
actually links or runs. It seems like the project itself has moved
away from newlib and to its own C library:
https://phoenix-rtos.com/documentation/libc/README.md
So since there's no interest from the phoenix folks to maintain this,
and it has a significant amount of non-standard code that we try to
keep up-to-date (without actually testing it), just punt it all.
The recent makefile reorganization broke the amdgcn port by creating
duplicate __malloc_lock symbols. This patch fixes the problem by renaming
the malloc_support.c file to mlock.c, thus overriding the default symbol
properly. Actually, I'm not sure how this ever worked?
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.
Integrate the old libm/test/ subdir into the main build. It hasn't
been used in a long time causing the code to rot a bit. I've fixed
some of those, but it still fails for many ports, so it's disabled
by default. People who want to take a closer look can run:
$ make libm/test/test
To help prevent people from missing running this script, integrate it
into the build via maintainer mode.
Also fix the inverted exit status to make this work correctly -- for
some reason, it exited 1 when it worked, and 0 when it failed.
Convert all the libc/ subdir makes into the top-level Makefile. This
allows us to build all of libc 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 libc.a. The
machine override logic is maintained though by way of Makefile include
ordering, and source file accumulation in libc_a_SOURCES.
There's a few dummy.c files that are no longer necessary since we aren't
doing the lib.a accumulating, so punt them.
The winsup code has been pulling the internal newlib ssp library out,
but that doesn't exist anymore, so change that to pull the objects.
Some awk implementations such as old versions of mawk do not support the
length() function. Use the return value of the POSIX split() function instead.
The current targ-include setup runs `cp` every header file it installs,
in serial. This can be a little noticeable on systems, so cleanup the
logic to rely on cp's ability to copy multiple files to a directory in
a single call.
We still need a check for empty directories with no headers (i.e. the
glob doesn't match anything), so add a helper variable to contain that
logic to reduce the boiler plate a little.
Since POSIX cp requires copying a file to a directory without having
to specify the name explicitly, rely on that to avoid calling basename
on every source file.
We can also drop the stub `true` call if the -f test failed. The use
of `if` already takes care of that in POSIX shell.
This kills off the last configure script under libc/ and folds it
into the top newlib configure script. The a lot of the logic was
already in the top configure script, so move what's left into a
libc/acinclude.m4 file.
I split libg.a out into a sep target from libc.a for the main dir in
commit f2b053f49e ("newlib: separate out
libg from libc"), but missed the multilib dirs. That leads to an
uncommon parallel build failure:
- libc.a rule runs & finishes
- $(BUILD_MULTISUBDIR)/libc.a rule runs
-> failure due to libg.a not yet existing
- libg.a rule runs & finishes
Split the multilib libg rule out from libc too so it can depend on the
main libg directly and avoid this race.
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
Sebastian Huber
Mike Frysinger
Andrew Stubbs
Jon Turney
Takashi Yano