Revert commit f54ec4e7f9 (libuv: macos: use posix poll instead of
kqueue, 2024-03-31, v3.29.1~7^2) and its parent. It is not necessary
after the kqueue-based implementation was fixed to reap child processes
more reliably.
Issue: #25839
Backport libuv commit `42cc412c4a` (darwin,process: feed kevent the
signal to reap children, 2023-02-01, `v1.45.0~55`) from libuv PR 3893.
Fixes: #25839
Upstream libuv supports passing file descriptors >= 3 to child processes
via `STARTUPINFOW` members reserved by the MSVC C run-time. However,
some programs use `GetStartupInfoW` to initialize a `STARTUPINFOW`
structure to pass to `CreateProcessW` without clearing the reserved
members. If we launch such programs with non-zero values in the
reserved members, the MSVC C run-time in *their* children may not
correctly associate the stdin/stdout/stderr streams' file descriptors
with the corresponding `HANDLE`s.
Patch our copy of libuv to avoid using the reserved members. This
restores `execute_process` support for the above-described programs as
we had prior to commit 5420639a8d (cmExecuteProcessCommand: Replace
cmsysProcess with cmUVProcessChain, 2023-06-01, v3.28.0-rc1~138^2~8).
It also enables support for such programs when launched by `ctest`.
Fixes: #25996Fixes: #25889
Since commit 5420639a8d (cmExecuteProcessCommand: Replace cmsysProcess
with cmUVProcessChain, 2023-06-01, v3.28.0-rc1~138^2~8) we've observed
spurious process hangs in `uv__io_poll` waiting for `kqueue` to deliver
events on macOS.
Issue: #25839
Since libuv commit `83efa3dd71` (Reland "macos: use posix_spawn instead
of fork", 2022-03-02, v1.44.0~10), `uv_spawn` on macOS < 10.8
has been observed to cause kernel panics and/or resource exhaustion.
This became particularly noticeable in CMake since commit 5420639a8d
(cmExecuteProcessCommand: Replace cmsysProcess with cmUVProcessChain,
2023-06-01, v3.28.0-rc1~138^2~8). Prefer `fork` over `posix_spawn` in
libuv when targeting macOS < 10.8.
Fixes: #25414Fixes: #25818
Inspired-by: Ken Cunningham <kencu@macports.org>
Backport libuv commit `3f7191e5` (win/spawn: optionally run executable
paths with no file extension, 2024-02-05, v1.48.0~8) to add the
`UV_PROCESS_WINDOWS_FILE_PATH_EXACT_NAME` option we now use.
Issue: #25450
This reverts commit fc6231bee5 (libuv: win/spawn: run executables with
no file extension, 2023-12-04, v3.28.0~9^2) to make room for the
corresponding fix from upstream libuv 1.48.
Record this as a merge from the last-imported upstream libuv snapshot
branch so that future `git blame` points to the upstream for the
original code instead of this commit.
Issue: #25450
Backport this commit from libuv PR 4241 to restore `execute_process()`
support for running executables on Windows with no file extension.
Fixes: #25450
This reverts commit da9df7425a (libuv: win/spawn: run executables with
no file extension, 2023-11-29, v3.28.0-rc6~1^2~1). It incorrectly
searched the `PATH` for extension-less command names. Another fix will
be needed for the regression motivating it.
Record this as a merge from the last-imported upstream libuv snapshot
branch so that future `git blame` points to the upstream for the
original code instead of this commit.
Fixes: #25473
Issue: #25450
Backport this commit from libuv PR 4241 to restore `execute_process()`
support for running executables on Windows with no file extension.
Fixes: #25450
Using the real `tcp.c` simplifies `cmake-bootstrap.c`, and its
implementation doesn't seem to require any of the platform-specific
definitions. Also, later it will be needed for `uv_socketpair`.
Divert LCC compiler as a new one, instead of treating it as GNU.
Since old times, Elbrus C/C++/Fortran Compiler (LCC) by MCST has been
passing checks for GNU compilers, so it has been identified as GNU.
Now, with intent of seriously upstreaming its support, it has been
added as a separate LCC compiler, and its version displays not a
supported GCC version, but LCC version itself (e.g. LCC 1.25.19 instead
of GNU 7.3.0).
This commit adds its support for detection, and also converts basically
every check like 'is this compiler GNU?' to 'is this compiler GNU or
LCC?'. The only places where this check is untouched, is where it
regards other platforms where LCC is unavailable (primarily non-Linux),
and where it REALLY differs from GNU compiler.
Note: this transition may break software that are already ported to
Elbrus, but hardly relies that LCC will be detected as GNU; still such
software is not known.
Since commit 43d6e5a71f (libuv: misc: add function to get CPU affinity
mask size, 2017-09-06, v3.12.0-rc1~412^2~3) we include `<sys/cpuset.h>`
on several BSD platforms but only use it on FreeBSD.
This is a backport of f9ad802fa5dd5afe6730f8e00cfdbf98f1d7a969
from the v1.x branch from upstream libuv:
mingw: fix building for ARM/AArch64
Don't use x86 inline assembly in these cases, but fall back to
__sync_fetch_and_or, similar to _InterlockedOr8 in the MSVC case.
This corresponds to what is done in src/unix/atomic-ops.h, where
ARM/AArch64 cases end up implementing cmpxchgi with
__sync_val_compare_and_swap.
PR-URL: https://github.com/libuv/libuv/pull/3236
Reviewed-By: Jameson Nash <vtjnash@gmail.com>
In commit 714ce72882 (bootstrap: Make libuv available during bootstrap,
2017-09-13, v3.10.0-rc1~106^2) we modified libuv to use POSIX interfaces
during bootstrap. However, some code still expects `TARGET_OS_IPHONE`
to be defined on Apple platforms to either `0` or `1`. In order to
offer this, include `<TargetConditionals.h>` on Apple platforms even
when bootstrapping.
libuv upstream commit `2475296c` (build: make code compilable for iOS on
Xcode, 2020-01-18, v1.35.0~47) added a `defined(TARGET_OS_IPHONE)`
preprocessor condition, but `TARGET_OS_IPHONE` is always defined on
Apple to either 0 or 1.
libuv upstream commit `4a972bf0` (aix: Fix broken cmpxchgi() XL C++
specialization., 2019-09-06, v1.32.0~5) broke compilation with this
compiler. According to
https://www.ibm.com/support/knowledgecenter/SSGH3R_16.1.0/com.ibm.xlcpp161.aix.doc/migrate/migrate_to_xlclang.html
XLClang 16.1 for AIX does not support `__sync_val_compare_and_swap`.
The documentation suggests using C++11 atomic operations instead, but
this is C code. For now fall back to the non-atomic equivalent used
before so we can at least compile. Add a FIXME comment for this.
Brad King