The MINGW32 build has been failing for a while because the MSYS2
repository has dropped MINGW32 versions of various packages in commit
6866be94df
I suppose nobody really uses 32 bit anymore. I'd like to have a 32
bit test of MPD, just to verify code correctness, but on the other
hand, I don't like solving problems like this MSYS2 packaging problem.
When nfs_destroy_context() is called while nfs_mount_async() is in
progress, libnfs invokes MountCallback(-EINTR) (but only if a NFS RPC
call is in progress; if the TCP connect is in progress, that callback
is not invoked).
If the mount operation had timed out, OnMountTimeout() set
mount_state=FINISHED, which triggered an assertion failure in
MountCallback(); this commit adds a check on whether the mount has
timed out and ignores the MountCallback.
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.
Max Kellermann