Skip to content

Make it work on FreeBSD#83

Draft
kentonv wants to merge 4 commits intomainfrom
kenton/freebsd
Draft

Make it work on FreeBSD#83
kentonv wants to merge 4 commits intomainfrom
kenton/freebsd

Conversation

@kentonv
Copy link
Member

@kentonv kentonv commented Oct 7, 2022

THIS IS NOT AN OFFICIALLY-SUPPORTED PLATFORM. Since we don't plan to have it in CI, it'll probably bitrot, but I'll be happy to accept patches to fix.

Since I had a FreeBSD VM set up to test capnproto/capnproto#1555 (which also benefits Mac, but testing on FreeBSD was easier), I thought it'd be fun to try to build the whole of workerd on FreeBSD. I managed to do so! With all tests passing!

However, this PR will NOT work out-of-the-box. You need some extra hacks:

  • Add --linkopt='-lm' --linkopt='-lexecinfo' --host_linkopt='-lm' --host_linkopt='-lexecinfo' to your bazel build or bazel test command line.
  • Symlink libstdc++.so to libc++.so, i.e. ln -s libc++.so /usr/lib/libstdc++.so, to work around a Bazel bug which will be fixed in 6.0 (but that's not released yet).
  • Move /usr/bin/clang to /usr/bin/clang.real and instead replace /usr/bin/clang with this script:
#! /usr/local/bin/bash

set -euo pipefail

FLAGS=("$@")
for I in "${!FLAGS[@]}"; do
  if [ "${FLAGS[$I]}" = '--target=x86_64-unknown-freebsd' ]; then
    unset -v 'FLAGS[$I]'
  fi
done

exec /usr/bin/clang.real "${FLAGS[@]}"

Obviously, the last hack is unreasonable, but without this I had persistent problems building //rust-deps. Specifically, when building the cxx crate, it would try to build the C++ source file scr/cxx.cc, but would not be able to find the libc++ library headers when doing so. It looks like this code is supposed to remove the -target flag, but is not designed to also recognize --target:

https://github.com/bazelbuild/rules_rust/blob/da3d522d59becbec5697dac0b2aa39890656ed4b/cargo/cargo_build_script.bzl#L16-L39

But I have no idea why this is needed or generally what is going on in this code. Moreover, I could not figure out how to tell it to use a different compiler binary (setting CC, CXX, etc. seemed to have no effect; it always used /usr/bin/clang no matter what I did). Otherwise, I could have placed by wrapper script somewhere else and pointed this code at that. Instead, I had to replace clang in its install location, which is awful.

It'd be great if some Bazel and/or FreeBSD expert could figure out what is needed here.

FreeBSD support is already in the codebase, but using GN, not Bazel. Making it work with Bazel wasn't too bad though.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant