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.
The `F_BARRIERFSYNC` constant was not added until the macOS 10.11 SDK.
Hard-code its value instead. This approach is backported from upstream
libuv PR 2334.
In commit beb991110d (Remove now-unused code once used on IRIX,
2019-01-11, v3.14.0-rc1~167^2) we removed remnants of IRIX support.
Also remove remnants of MIPSpro compiler support.
