intentional @compileError limits zig to a very narrow band of posix systems

[jrmarino]

zig/lib/std/os.zig

Lines 5284 to 5300 in aea617c

	.freebsd => {
	comptime if (builtin.os.version_range.semver.max.order(.{ .major = 13, .minor = 0 }) == .lt)
	@compileError("querying for canonical path of a handle is unsupported on FreeBSD 12 and below");
	var kfile: system.kinfo_file = undefined;
	kfile.structsize = system.KINFO_FILE_SIZE;
	switch (errno(system.fcntl(fd, system.F.KINFO, @ptrToInt(&kfile)))) {
	.SUCCESS => {},
	.BADF => return error.FileNotFound,
	else => |err| return unexpectedErrno(err),
	}
	const len = mem.indexOfScalar(u8, &kfile.path, 0) orelse MAX_PATH_BYTES;
	mem.copy(u8, out_buffer, kfile.path[0..len]);
	return out_buffer[0..len];
	},
	else => @compileError("querying for canonical path of a handle is unsupported on this host"),

so zig 10.0.0 will intentionally does not compile on < FreeBSD 13 and not at all on DragonFly or NetBSD?

There wouldn't be a reason to leave it in Ravenports if that's the case.

[nektro]

.netbsd and .dragonfly get their own OS values respectively

edit: see std.Target.Os.Tag

[leecannon]

Also this compile error is only hit if someone calls getFdPath on < FreeBSD 13, if they don't try to get the path of an fd then no compile error.

[jrmarino]

I understand the code. The point is that they don't have it now, which means it doesn't build now.
And @leecannon is incorrect. It doesn't compile. I assume that's the point of @compilerror

More to the point, there should be code to fallback on, not a compile error.

What other projects have done in cases like this is return nothing, perhaps with some kind of emitted notice.

Unless zig is intentionally supporting ONLY FreeBSD (and linux, macos, windows) the current state shouldn't be acceptable.

@compileError only triggers a compile error if it is semantically analyzed. If getFdPath is never called, its body is never semantically analyzed, so the program will compile.

What other projects have done in cases like this is return nothing, perhaps with some kind of emitted notice.

I think this is very much a bad idea and contrary to Zig's values. If you're calling an API that doesn't exist on your platform, you should find out about that as soon as possible. If you really want it to fall back on returning null, you could branch on builtin.os.tag yourself and use null instead of calling the function on FreeBSD < 13. It should be explicit. And Zig does not have warnings, so it's either a compile error or quietly doing something incorrect at runtime.

[jrmarino]

I'm not sure what your point is.
I found it because zig 9 compiles on DragonFly and trying to update to zig 10 failed to compile on DragonFly.
Ravenports is still using FreeBSD 12.2 as the basis of FreeBSD packaged software. I have not attempted to compile it there, but I fully expect it to also fail to compile, because it will be semantically analyzed.

The bottom is at least 2 platforms stopped building between zig 9 and zig 10. I cannot remember if our netbsd packages included zig yet or not, so that could be 3 platforms.

so you are leaving me with 3 choices:

1. stay at zig 9
2. move to zig 10 and remove support for dragonfly, freebsd, and netbsd (at least until RP moves to base packages on FreeBSD 13 or later)
3. just remove the port completely

Obviously I'm not going to try to implement the missing functionality

[nektro]

if you're on dragonfly and zig is detecting it as freebsd, that's a different issue, and a valid one for sure

[mikdusan]

Unfortunately, it seems os.getFdPath() is referenced in the normal course of building zig. I think it's indirect via os.realpath() implementation.

At a quick glance, perhaps on platforms where libc is used, the impl be changed to use libc's realpath() instead of getFdPath() .

EDIT: err wait. It already does that! gonna have to dig a bit further and find out what is causing getFdPath() to be analyzed.

[jrmarino]

@nektro no it's not a case of dragonfly being identified as freebsd. I was just saying that I was building on Dragonfly, but I expect to hit the same issue on FreeBSD 12.2.

[semarie]

My digging is it comes from realpathAlloc() call from src/Compilation.zig, which call Dir.realpath(), which call Dir.realpathZ(), which call getFdPath()

[squeek502]

Unless zig is intentionally supporting ONLY FreeBSD (and linux, macos, windows) the current state shouldn't be acceptable.

This is an unintentional regression. Looks like it was introduced in 9db2934 via #12540