MPD stopped building since fmt 11.1.0; see
<https://github.com/fmtlib/fmt/issues/4304>. The first commit
fixing this was 9db7144, followed by 5de0909 (both on the
unstable branch).
This commit removes what the author believes to be the remaining
uses in the MPD codebase.
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.
Let sqlite do the work for incrementing or decrementing a sticker value.
This sub-commands are usefull to track playcounts with sticker values and
saves us one roundtrip.
If binding one address fails, we don't need to close all listeners.
For fatal errors, this will be done automatically and implicitly; and
for non-fatal errors (e.g. binding to the default port failed, but
there is an XDG listener), this closes the good listeners which are
supposed to be used.
Closes https://github.com/MusicPlayerDaemon/MPD/pull/2157
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
Opening a FIFO may block indefinitely (until a writer connects). This
is dangerous because it may be a DoS vulnerability in many programs
that do not expect open() to block.
This obsoletes the method FileDescriptor::OpenNonBlocking() which
wasn't used anyway.
