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
This reverts commit 94b5b9f370. It was
not necessary for branch v0.23.x because there, Break() is
thread-safe; this was only changed later by commit
a3b32819b1
snd_pcm_poll_descriptors_revents() may return any error code; the
ALSA docs do not constrain the permitted values. A 'hw' device
will only ever return an error if the pfd array passed in is
invalid (-EINVAL), but other I/O plugins may return arbitary
errors. For example a network-based device may return -EPIPE etc.
The resulting exception thrown by
AlsaNonBlockPcm::DispatchSockets() must be caught to prevent the
mpd process from being aborted.
Some ALSA capture devices can have very large buffers, holding 10
seconds or more audio. Using the maximum buffer size with such
devices leads to unacceptably large, and unnecessary, latency.
Also, some ALSA drivers (e.g. HDA Intel PCH) report an invalid
maximum period size, and the period size that mpd calculates from
the maximum buffer size results in "Invalid argument" error when
applying the hw_params. Note that the "default" capture device on
many cards includes the "dsnoop" plugin which imposes a buffer
size of 16384 frames, so that "alsa://" works OK but
"alsa://plughw" or "alsa://hw" both fail.
Limit the maximum buffer time for ALSA input devices to a more useable
2 seconds, thereby avoiding both the above problems.
Max Kellermann