- Currently, if cat is started from cmd.exe which is started in cygwin
console, Ctrl-C terminates not only cat but also cmd.exe. This also
happens in pty in which pseudo console is disabled. This patch fixes
the issue.
No functional changes here, just fix warnings the compiler noticed.
bfin/syscalls.c:156:13: warning: conflicting types for built-in function ‘memset’
bfin/syscalls.c: In function ‘_unlink’:
bfin/syscalls.c:193:3: warning: passing argument 2 of ‘do_syscall’ discards qualifiers from pointer target type
bfin/syscalls.c:33:1: note: expected ‘void *’ but argument is of type ‘const char *’
bfin/syscalls.c: In function ‘_exit’:
bfin/syscalls.c:104:1: warning: ‘noreturn’ function does return
Compiling the basiccrt .S files missed an include to the local bfin/
headers causing the build to break when installing anew.
Reported-by: Jeff Law <jeffreyalaw@gmail.com>
These look like they were just copied & pasted from common/Makefile.am.
The funcs in this dir are all stubs that don't actually call any math
or builtin functions, and a simple compile shows they produce identical
object code. So delete to simplify the build rules.
It looks like csky was created by copying & pasting the m68k port,
but m68k-specific stuff was left over related to target selection.
The makefile doesn't do anything with it, so punt it all to make
the file much simpler.
- Currently, ENABLE_INSERT_MODE and ENABLE_QUICK_EDIT_MODE are cleared
if cygwin is started in console. These flags will not be recovered
even when exiting from cygwin. Also note that if ENABLE_EXTENDED_FLAGS
is once unset, then the flag ENABLE_QUICK_EDIT_MODE it's associated
with will no longer be preserved. Unfortunately, we're accidentally
stepping on this in fhandler_console::set_input_mode().
This patch solves this by carrying forward these flags in the place
where it had been ignoring them. Since the previous behaviour of
leaving these flags unset would essentially maintain their existing
state, adding the carry-over of the flags now should not alter console
behaviour.
Correct the overflow limit in the variable o_threshold to be consistent
with the FLT_UWORD_LOG_MAX variable used by the internal implementation
of the expf algorithm itself.
The u_threshold variable has also been modified to be written in the
same format.
Note that this fix improves the situation but does not completely
correct the inconsistencies regarding the overflow and underflow limits
between the expf wrapper (wf_exp.c) and the expf algorithm itself
(ef_exp.c).
Currently these limits are different for the
_FLT_LARGEST_EXPONENT_IS_NORMAL and _FLT_NO_DENORMALS cases as well as
for the case where __OBSOLETE_MATH is not defined (only for the
underflow limit in this case).
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.
This was only used by the i?86-pc-linux-gnu target which we've removed,
and even though it's using a "sys/linux/" dir to make it sound like it
only depends on the Linux kernel, it's actually tied to glibc APIs built
on top of Linux. Since the code relies on internal glibc APIs and has
been broken for some time, punt it all. If someone wants to bring it
back, they can try and actually keep the Linux-vs-glibc APIs separate.
This was added 20+ years ago. It seems to have very few (or no users)
as it only works on 32-bit x86 GNU/Linux (i.e. glibc) systems, and even
then only with old versions of glibc. It hasn't compiled in at least 5
years, but most likely been broken for more like 15 years -- it relies
on internal glibc APIs (like linuxthreads), and that code has changed
and been deleted significantly since.
This single target ends up dragging in a lot of non-trivial code that is
hard to keep working, and currently impossible to verify -- the libtool
and iconvdata and sys/linux/ code isn't used by anything else, but ends
up touching just about every build file in the tree. Punt the target so
we can start stripping out all these unique code paths.
This commit by itself just disables the target. We'll start deleting the
individual unused pieces in followups.
The top level dir isn't doing anything interesting, just recursing into
subdirs. So this change isn't terribly exciting. But it sets us up for
doing more fun stuff in follow up commits.
[TODO] Check test targets
The common $DO variable is used by the multilib logic to control which
target to multiplex. But the m68k subdir is also using $DO to control
which target (m68k or fido) to build. As we flatten things to automake,
this conflict shows up and breaks the m68k build. Just rename the m68k
variable to something unique to avoid it.
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.
This code is a bit more convoluted than it needs to be. GPR_SOURCES
is never set to anything, and the automake checks use negative logic
to add the SP & DP source files to dedicated variables that are only
expanded once. Get rid of the unused variable, use normal boolean
logic, and collapse the source settings into a single variable.
On second thought, we don't actually need this script.
Express the entire action as sufficiently simple Makefile rule.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
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.
THe stdio subdir is actually required by the documentation. The
stdio/def is handled dynamically, but libc.texi always expects it
to be included, and fails if it isn't. So making it required when
building docs is safe.
The xdr subdir is handled dynamically, but it doesn't include any
docs, so the dynamic logic isn't (currently) adding any value. So
making it required when building docs is safe.
That leaves: iconv, stdio64, posix, and signal subdirs. The chapters
have a little disclaimer saying they are system-dependent, but even
then, imo having stable manuals regardless of the target is preferable,
and we can add more disclaimer language to these chapters if we want.
This doesn't touch the man page codepaths, just the info/pdf.
Commit 754f8def0d ("libgloss: merge stub
arch configure scripts up a level") had an unintended side-effect: the
MULTI* variables in the Makefiles no longer get rewritten at configure
time in the subdirs. Only the top-level Makefile still is. This is
because the configure integration of multilib (both the way libgloss
did it manually and the way AM_ENABLE_MULTILIB does it) only rewrites
"Makefile".
We could try propagating the MULTI* variables from libgloss/Makefile
down via FLAGS_TO_PASS, but this runs into a limitation: the multilib
logic uses this variable to switch from libgloss/ to each multilib
libgloss/, and libgloss uses this variable to enter subdirectories.
The latter we want, but the former ends up overridding the Makefile
environment. We could side-step that with some GNU Make directives,
but it feels like we're getting a bit too deep down the rabbit hole.
Instead, let's call config-ml.in ourselves for each subdir Makefile
that the top-level configure generates. This restores the previous
behavior and should be less risky in general.
This logic should be unnecessary when/if we switch libgloss over to
a non-recursive Automake build (since all build+install settings are
in the single libgloss/Makefile), but it'll be a while before we can
land that rework, so let's fix this up now.
- formatting
- use array pointer as argument rather than variable arguments
- syntactical fixes
- add comments
- drop unnecessary recomputation of all section VMAs.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
Let automake manage whether the objects are included in lib.a. This
fixes failures after to commit 71086e8b2d
("newlib: delete (most) redundant lib_a_CCASFLAGS=$(AM_CCASFLAGS)") due
to automake generating different set of implicit rules, and the code in
here assuming the names of the generated objects.
In Makefile.am, add the value of $(V) to the dllfixdbg call.
In dllfixdbg, if V=1, print what the script is doing.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
Change dllfixdbg to keep the input DLL intact and just generate
a new DLL matching the debug file. Fix Makefile rule accordingly.
The result is, cygwin0.dll is the original DLL created with full
debug sections and stays that way throughout the build process.
Only new-cygwin1.dll will become the stripped DLL matching with
the file containing the debug sections cygwin1.dbg. This is ok,
because commit ba02fef995 ("Cygwin: Makefile.am: fix DLL build rule")
made new-cygwin1.dll the DLL to be installed.
Signed-off-by: Corinna Vinschen <corinna@vinschen.de>
- If an UNC path is mounted to a drive using SMB3.11, accessing to
the drive fails with error "Too many levels of symbolic links."
This patch fixes the issue.
Takashi Yano
Mike Frysinger
Mitchell Hentges
Andoni Arregi
Corinna Vinschen