Draft
Conversation
FreeBSD support is already in the codebase, but using GN, not Bazel. Making it work with Bazel wasn't too bad though.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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:
--linkopt='-lm' --linkopt='-lexecinfo' --host_linkopt='-lm' --host_linkopt='-lexecinfo'to yourbazel buildorbazel testcommand line.libstdc++.sotolibc++.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)./usr/bin/clangto/usr/bin/clang.realand instead replace/usr/bin/clangwith this script:Obviously, the last hack is unreasonable, but without this I had persistent problems building
//rust-deps. Specifically, when building thecxxcrate, it would try to build the C++ source filescr/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-targetflag, 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/clangno matter what I did). Otherwise, I could have placed by wrapper script somewhere else and pointed this code at that. Instead, I had to replaceclangin its install location, which is awful.It'd be great if some Bazel and/or FreeBSD expert could figure out what is needed here.