Why does posix.recv require libc on Windows?

Help
,
1

zig version 0.15.2. Build the following code with zig build-exe -target x86_64-windows-gnu main.zig fails. Error message is dependency on libc must be explicitly specified in the build command.

const std = @import("std");
const posix = std.posix;
pub fn main() !void {
	const fd = try posix.socket(posix.AF.INET, posix.SOCK.STREAM, 0);
	defer posix.close(fd);
	_ = try posix.recv(fd, &[_]u8{}, 0);
}

Adding -lc after zig build-exe fixes the compilation error. Removing the posix.recv line without adding -lc also fixes the error.

I’m quite confused. I assume the socket family functions are from ws2_32.dll. Is ws2_32 part of libc on Windows? Why does posix.recv require libc while posix.socket doesn’t? Thanks for any help!

2

many posix functions require libc on windows, I can only guess why that is.

my guess is adapting windows apis to a posix interface is a significant amount of work, work that its libc already does. Zig only provides its own implementation for the easier or more needed (by the compiler) apis.

3

I’ve got some clue after some digging. There are 2 recvfrom implementations for Windows.

// std.c.recfrom
pub extern "c" fn recvfrom(
    sockfd: fd_t,
    noalias buf: *anyopaque,
    len: usize,
    flags: u32,
    noalias src_addr: ?*sockaddr,
    noalias addrlen: ?*socklen_t,
) if (native_os == .windows) c_int else isize;
// std.os.windows.ws2_32
pub extern "ws2_32" fn recvfrom(
    s: SOCKET,
    buf: [*]u8,
    len: i32,
    flags: i32,
    from: ?*sockaddr,
    fromlen: ?*i32,
) callconv(.winapi) i32;

std.posix.recv indirectly calls std.c.recvfrom, which seems to come from mingw-w64-crt and depends on bunch of mingw libraries including libmingw32. libmingw32 is considered libc by zig, so zig reports libc is required. The system ws2_32.dll is not part of libc. So if I don’t want to link against libc, I should write my own wrapper recvfrom which calls std.os.windows.ws2_32.recvfrom.

2 Likes
4

std.posix seems not very usable for Windows socket programming right now. posix.close calls CloseHandle, while for a SOCKET fd it should be closesocket.
posix.sendto uses ws2_32 while posix.recvfrom uses mingw. Windows is not a POSIX OS after all :upside_down_face:

5

I see these APIs are being removed from std.posix.

6

Overall, Windows itself is not compatible with the POSIX standard, but developers accustomed to the POSIX ecosystem use some wrapper libraries to wrap Windows native operations into partial POSIX APIs. Mingw is the most popular wrapper library of this kind, which is also the default libc selected by Zig on Windows.

1 Like