Add FreeBSD cargo-zigbuild remote_server support

[G36maid]

Work-in-progress to enable connecting to FreeBSD remote servers from Zed.

Full details: I've documented everything in a report

https://gist.github.com/G36maid/c2aff8c1561b307f38f9e1b3aff215e1

Summary

Four categories of changes that unblock FreeBSD remote development without affecting existing platforms:

• crashes crate: Gate crash-handler/minidumper behind cfg(not(target_os = "freebsd")) since neither crate supports FreeBSD. A no-op stub module provides the same public API so remote_server compiles and links without them.
• gpui: Add target_os = "freebsd" to the queue module cfg gates — FreeBSD has the same POSIX APIs as Linux here.
• fs: Fix MaybeUninit usage in current_path() — zeroed() + assume_init_mut() instead of uninit() + as_mut_ptr(), which is UB when accessing fields of uninitialized memory.
• remote: Add FreeBSD to the RemoteOs enum and parse_platform() so the Zed client recognizes FreeBSD remotes without requiring a uname wrapper hack. Maps to the unknown-freebsd target triple.

No behavioral change on any existing platform. All FreeBSD-specific code paths are gated behind cfg(target_os = "freebsd").

Remaining blockers ( Already solved )

• libz-sys always vendors zlib when cross-compiling, producing non-PIC .o files that fail PIE linking on FreeBSD. Root cause: libz-sys's build.rs forces building from source on cross_compiling && !apple without ensuring -fPIC. Workaround: point ZLIB_LIB_DIR to a FreeBSD sysroot and patch build.rs to link the pre-built libz.so instead. Upstream issue pending.
• cargo-zigbuild: Ignores -L paths for dynamic library resolution on FreeBSD targets, requiring explicit .so file paths in RUSTFLAGS.

building

prepare commands:

mkdir -p ~/freebsd-sysroot
curl -L -o /tmp/base.txz \
  https://download.freebsd.org/releases/amd64/amd64/15.0-RELEASE/base.txz

# Extract only the lib/ and usr/ directories
tar -xJf /tmp/base.txz -C ~/freebsd-sysroot ./lib ./usr

build commands:

CFLAGS_x86_64_unknown_freebsd="\
    -fPIC \
    -I$HOME/freebsd-sysroot/usr/include \
    -L$HOME/freebsd-sysroot/lib \
    -L$HOME/freebsd-sysroot/usr/lib" \
RUSTFLAGS="\
    -L $HOME/freebsd-sysroot/lib \
    -L $HOME/freebsd-sysroot/usr/lib \
    -C link-arg=$HOME/freebsd-sysroot/usr/lib/libkvm.so \
    -C link-arg=$HOME/freebsd-sysroot/usr/lib/libprocstat.so" \
cargo zigbuild -p remote_server --release --target x86_64-unknown-freebsd

Testing

Cross-compiled remote_server for x86_64-unknown-freebsd from Arch Linux, deployed to FreeBSD 15.0-RELEASE, and verified a successful remote connection from the Zed client.

Release Notes:

• N/A

[ConradIrwin]

Amazing, thank you!

It wasn't clear from the report is the libz-sys thing fixable in that crate, or will we have to fork?

I assume that the Ubuntu builders we currently use are going to be "similar enough" to the Arch one that we can copy this in.

For the crash handler, is that something we could make work, or is that a limitation of mini dump?

[G36maid]

@ConradIrwin

libz-sys — fixable or need to fork?

Good news — this is already fixed upstream. libz-sys PR 244 (rust-lang/libz-sys#244) (merged July 2025, available in v1.1.26+) removed the forced static vendored build on cross-compile. The old build.rs had cross_compiling && !apple which forced building zlib from source without -fPIC. That condition is now gone, so newer libz-sys will attempt dynamic linking first.

For Zed's current version (1.1.22 per Cargo.lock), we'd either:

1. Upgrade libz-sys to ≥1.1.26, or
2. Keep the [patch.crates-io] override in the PR (which links the sysroot's libz.so)

There's also an open PR 206 https://github.com/rust-lang/libz-sys/pull/206 for a LIBZ_SYS_STATIC=0 env var to force dynamic linking.

Ubuntu builders similar enough to Arch?

Yes ,they are same.

Crash handler — can we make it work?

Not fundamentally limited — just unimplemented. The crash-handler maintainer confirmed (EmbarkStudios/crash-handling#108) that since FreeBSD has ptrace(), adding support "might not be too much work." The dependency chain is: Zed → crash-handler → minidump-writer. Maintainers are receptive to contributions.

For the remote server use case, crash reporting is non-essential, so the no-op stubs are fine for now. If Zed wants proper crash reporting on FreeBSD later, the path is contributing a FreeBSD backend to minidump-writer (which would unblock crash-handler and then Zed).

[G36maid]

Already bump the libz-sys version, nothing break.

Current runable build command

CFLAGS_x86_64_unknown_freebsd="\
    -fPIC \
    -I$HOME/freebsd-sysroot/usr/include \
    -L$HOME/freebsd-sysroot/lib \
    -L$HOME/freebsd-sysroot/usr/lib" \
RUSTFLAGS="\
    -L $HOME/freebsd-sysroot/lib \
    -L $HOME/freebsd-sysroot/usr/lib \
    -C link-arg=$HOME/freebsd-sysroot/usr/lib/libkvm.so \
    -C link-arg=$HOME/freebsd-sysroot/usr/lib/libprocstat.so" \
cargo zigbuild -p remote_server --release --target x86_64-unknown-freebsd

[G36maid]

We also need to add a binary download function for freebsd side.
After make the release pipeline working.

[ConradIrwin]

Amazing, thanks! Happy to merge this. I don't see the libz change in the diff though?

Once this is merged, are you ok to take a pass at adding a freebsd build to the workflows? Otherwise I can have claude do it when I get some downtime. Once I have something to test, I'll need you to check that the built binary actually works :D

[G36maid]

For the libz change, it was just a version bump. The changes are only reflected in Cargo.lock, which GitHub collapses by default—you'll need to click "Load diff" on the lockfile to see it.

And yes, I'd be happy to take a pass at adding the FreeBSD build to the workflows next!
I'll split that into a separate PR.

I can test the built binary on my end once the CI is set up.

[ConradIrwin]

Thanks! Looks like cargo fmt is busted, and can we revert 4a8a61e? I think it was much clearer before