This way, we avoid calling the FormatNfsClientError() which crashes
when nfs_get_error() returns nullptr; that can happen on RPC errors:
then, libnfs's check_nfs4_error() doesn't call nfs_set_error().
Closes https://github.com/MusicPlayerDaemon/MPD/issues/2040
There were a few macOS related bug reports on the bug tracker which
have been open for years without a volunteer caring for them. The
GitHub actions build has also been broken for a long time due to bugs
in the ancient LLVM toolchain shipped with macOS, making macOS an
unsuitable non-Linux target for testing MPD's portability.
All of this makes macOS support an annoying liability for me. To
avoid more frustration, I'm hereby dropping macOS support completely
from MPD. Maybe this causes enough pain for a new maintainer to
spawn, but maybe nobody cares, so... let's see.
The Brew package of yajl is broken, it fails to build:
In file included from ../src/lib/yajl/Handle.cxx:4:
In file included from ../src/lib/yajl/Handle.hxx:6:
/opt/homebrew/Cellar/yajl/2.1.0/include/yajl/yajl_parse.h:22:10: fatal error: 'yajl/yajl_common.h' file not found
#include <yajl/yajl_common.h>
^~~~~~~~~~~~~~~~~~~~
1 error generated.
Therefore, MPD cannot support building with yajl on macOS.
According to the yajl API documentation, #include lines should have
the "yajl/" path prefix, but the actual pkg-config file contains:
includedir=${dollar}{prefix}/include/yajl
.. which already contains this directory name, and thus the "yajl/"
prefix cannot work. Unfortunately, the yajl project hasn't been
maintained for nearly 10 years, and there's little chance this bug
will ever be fixed.
This reverts commit 669cbcd25a
("util/IntrusiveList: allow the last disposer to destroy the
IntrusiveList"). It was bad because it could lead to off-by-one crash
bugs when the last item was removed inside the previous item's
disposer.
We need a different solution for the other crash bug that was fixed by
the reverted commit.
Without this, calling CancelRead() after ScheduleRead() would leave
the HANGUP scheduled, and the caller could receive HANGUP events over
and over which are never properly handled, leading to a busy loop.
The semantics of this API are hard to get right, because the
IMPLICIT_FLAGS (a property of epoll) are somewhat weird. But it seems
that this change repairs a side effect of the SocketEvent interface
that seemed counterintuitive.
Max Kellermann