Seems like the latest nightly broke something in the std::os::unix::net module, for which now the maximum backlog number for horizonOS seems to be set to libc::SOMAXCONN, a constant we obviously do not include. This is the referred line.
We already had problems in the past that made us set the maximum backlog number to 20 for std::sys_common::net (right here), but I guess no action was taken for UnixListener.
To be completely honest, I don't know whether horizon supports UnixListener fully, but this might be a chance to add a new const to libc that might be used by external crates. Otherwise, we can simply add a #[cfg(target_os = "horizon")] and set our own value within std. In the mean time, the CI fails on the latest nightly. :(
Seems like the latest nightly broke something in the
std::os::unix::netmodule, for which now the maximum backlog number forhorizonOSseems to be set tolibc::SOMAXCONN, a constant we obviously do not include. This is the referred line.We already had problems in the past that made us set the maximum backlog number to
20forstd::sys_common::net(right here), but I guess no action was taken forUnixListener.To be completely honest, I don't know whether
horizonsupportsUnixListenerfully, but this might be a chance to add a newconsttolibcthat might be used by external crates. Otherwise, we can simply add a#[cfg(target_os = "horizon")]and set our own value withinstd. In the mean time, the CI fails on the latest nightly. :(