A new symlink causes `IN_CREATE`. Usually, we catch `IN_CREATE` only with
IN_ISDIR to watch the new directory, but otherwise `IN_CREATE` is not
handled. Regular files are "created" but they have usable content
only with `IN_CLOSE_WRITE`. Yet symlinks have only `IN_CREATE` and
they are immediately usable.
Closes https://github.com/MusicPlayerDaemon/MPD/issues/2192
libnfs version 6 has major API changes and MPD 0.23 has never been
adapted to these. This additional configure-time check fixes
potential compile-time failures.
This yajl on Homebrew comes with broken headers:
/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>
^~~~~~~~~~~~~~~~~~~~
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.
When compiling with libfmt-11.1.0 and newer the following compile errors occur:
In file included from ../src/decoder/DecoderPrint.cxx:23:
../src/client/Response.hxx: In instantiation of 'bool Response::Fmt(const S&, Args&& ...) [with S = decoder_plugin_print(Response&, const DecoderPlugin&)::<lambda()>::FMT_COMPILE_STRING; Args = {const char* const&}]':
../src/decoder/DecoderPrint.cxx:38:7: required from here
38 | r.Fmt(FMT_STRING("plugin: {}\n"), plugin.name);
| ~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../src/client/Response.hxx:86:28: error: cannot convert 'const decoder_plugin_print(Response&, const DecoderPlugin&)::<lambda()>::FMT_COMPILE_STRING' to 'fmt::v11::string_view' {aka 'fmt::v11::basic_string_view<char>'}
86 | return VFmt(format_str,
| ~~~~^~~~~~~~~~~~
87 | fmt::make_format_args(args...));
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
../src/client/Response.hxx:81:36: note: initializing argument 1 of 'bool Response::VFmt(fmt::v11::string_view, fmt::v11::format_args)'
81 | bool VFmt(fmt::string_view format_str, fmt::format_args args) noexcept;
| ~~~~~~~~~~~~~~~~~^~~~~~~~~~
../src/client/Response.hxx: In instantiation of 'bool Response::Fmt(const S&, Args&& ...) [with S = decoder_plugin_print(Response&, const DecoderPlugin&)::<lambda()>::FMT_COMPILE_STRING; Args = {const char* const&}]':
The error is due to the use of FMT_STRING. The libfmt team shared the following:
The correct way of using FMT_STRING is to wrap a format string when passing to a
function with compile-time checks (i.e. that takes format_string) as documented
in https://fmt.dev/11.1/api/#legacy-compile-time-checks.
Noting that FMT_STRING is a legacy API and has been superseded by consteval-based
API starting from version 8: https://github.com/fmtlib/fmt/releases/tag/8.0.0. It
looks like MPD is trying to emulate {fmt}'s old way of implementing compile-time
checks which was never properly documented because it was basically a hack. So the
correct fix is to switch to format_string and, possibly, remove usage of FMT_STRING.
The old way of doing compile-time checks (fmt::make_args_checked) was documented
in https://fmt.dev/7.1/api.html#argument-lists but it looks like MPD is not using
that API so the problematic uses of FMT_STRING have no effect and can just be removed.
The FMT_STRING has been removed in this change based on the fmt-7.1 API and now MPD is
successfully compile against the current libfmt-11.1.0 which highlighted the issue that
had been present in the codebase as it is now triggering the error, is legacy and was
not using the API for which FMT_STRING was aligned with.
Previously, inode numbers were truncated to 32 bits, which could lead
to problems on XFS where inodes are 64 bit; this could lead to bogus
"recursive directory found" errors during database update.
[mk: added commit description and NEWS line]
Closes https://github.com/MusicPlayerDaemon/MPD/issues/2000
ICU 76 decided to reduce overlinking[^1] thus `icu-i18n` will no longer
add `icu-uc` when linking to shared libraries. This results in failure:
```
src/lib/icu/libicu.a.p/Converter.cxx.o: undefined reference to symbol 'ucnv_fromUnicode_76'
```
[^1]: 199bc82702
Closes https://github.com/MusicPlayerDaemon/MPD/issues/2151
