| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
Tell the compiler the structs are layout-compatible.
|
|
|
|
|
|
| |
# By libuv upstream
* upstream-libuv:
libuv 2022-01-13 (2fbfa035)
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
* upstream-libuv:
libuv 2021-11-09 (0f696da5)
|
|
|
|
|
|
| |
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.
|
|\
| |
| |
| |
| |
| |
| | |
1aba3a8367 libuv: Fix building with mingw toolchains for ARM/AArch64
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !6354
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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>
|
|/
|
|
|
|
|
| |
Fix libuv issue 3159 in CMake while integration in upstream libuv is
pending.
Fixes: #22141
|
|
|
|
| |
Detect MSYS as CYGWIN, with the required adaptations.
|
| |
|
| |
|
| |
|
|
|
|
|
| |
Add a cast to avoid the conversion warning with minimal changes to
third-party code.
|
|
|
|
|
| |
This is now called by `uv__fs_sendfile` in `src/unix/fs.c` but we do not
need that feature during CMake bootstrap.
|
|
|
|
|
| |
* upstream-libuv:
libuv 2020-09-22 (ed5b42d5)
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
These are now called by `uv_library_shutdown` in `src/uv-common.c` but
on UNIX we do not compile those features during CMake bootstrap.
|
|
|
|
|
| |
* upstream-libuv:
libuv 2020-04-29 (e7ebae26)
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
* upstream-libuv:
libuv 2020-04-06 (d21f5aea)
|
| |
|
|
|
|
|
| |
Port enough of libuv to HP-UX 11.31 ia64 with GCC 4.9.3 to work for
CMake.
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
| |
* upstream-libuv:
libuv 2019-06-10 (ee24ce90)
|
| |
|
| |
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
| |
Headers in `uv/` can include each other without the `uv/` prefix. Using
the prefix assumes that the location of `uv/` is in the include file
search path, but it is possible to include `uv.h` via a longer path.
|
|
|
|
|
| |
* upstream-libuv:
libuv 2019-01-15 (f84c5e69)
|
| |
|
|\
| |
| |
| |
| |
| |
| | |
3c0bfb596f libuv: do not require PATH_MAX to be defined
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !2422
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Some platforms (e.g. GNU/Hurd) do not define PATH_MAX. Add a few other
variants and a fallback constant. Also use alternatives where possible:
* For readlink(), use lstat() to read the length of the link first.
If it is not a symlink, report EINVAL before trying to allocate.
If the size reports as zero, fall back one of the PATH_MAX variants.
* For realpath(), POSIX 2008 allows us to pass a NULL buffer
to tell it to malloc() internally.
This patch was inspired by downstream patches in Debian packaging
for issues 897061 and 909011.
Issue: #18337
|
|/
|
|
| |
Issue 18375
|
| |
|
|
|
|
|
| |
* upstream-libuv:
libuv 2018-05-06 (bf605bd7)
|
|\
| |
| |
| |
| |
| |
| | |
1c22fdf360 libuv: linux/sparc64: use fcntl to set and clear O_NONBLOCK
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !2029
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Upstream libuv commits:
* node-v0.6.0~28 (linux: use ioctl(FIONBIO) to set O_NONBLOCK, saves a syscall, 2011-10-29)
* v1.11.0~11 (unix: use async-signal safe functions between fork and exec, 2016-12-12)
left an asymmetry in the way O_NONBLOCK is set and cleared. Normally
ioctl/FIONBIO is used for both. However, uv_spawn uses fcntl/O_NONBLOCK
to clear O_NONBLOCK between fork and exec. This fails on Linux/sparc64
where setting via ioctl/FIONBIO actually sets two bits (in O_NDELAY)
that cause clearing via fcntl/O_NONBLOCK to be silently ignored (though
clearing via ioctl/FIONBIO or fcntl/O_NDELAY works).
Since CMake commit v3.11.0-rc1~117^2 (CTest: Re-implement test process
handling using libuv, 2017-12-10), CTest uses libuv. On Linux/sparc64
child processes have been started with non-blocking output pipes. This
can lead to write errors or lost output from children not prepared to
deal with `EAGAIN` on stdout or stderr.
Fix this for now by switching libuv back to fcntl/O_NONBLOCK to set and
clear O_NONBLOCK when compiled on Linux/sparc64.
LibUV-Issue: 1830
Fixes: #17941
|
| |
| |
| |
| | |
Avoid depending on platform-specific pthread features during bootstrap.
|
| |
| |
| |
| |
| |
| |
| |
| | |
Implement it on Linux, FreeBSD, and Windows for now, and fail with
UV_ENOTSUP on other platforms.
Backported from upstream libuv PR 1527, scheduled for inclusion
in libuv 2.0.
|
|/
|
|
|
|
|
|
| |
Implement it on Linux, FreeBSD, and Windows for now, and return
UV_ENOTSUP on other platforms.
Backported from upstream libuv PR 1527, scheduled for inclusion
in libuv 2.0.
|
|
|
|
| |
Update our CMake build rules to account for upstream changes.
|