Allow a bootstrap build of Bazel on OpenBSD to succeed.

[aldersondrive]

Tested on OpenBSD 6.6-current (amd64 architecture), as follows:

# Create a 'dist' tarball. Here, `bbazel` is a binary left over from the
# porting work leading up to this patch.
cd ~/git/aldersondrive_bazel
/home/me/bin/bbazel build --host_javabase=@local_jdk//:jdk :bazel-distfile

# Perform a bootstrap build based on the tarball.
rm -rf ~/test_bootstrap
mkdir ~/test_bootstrap
cd ~/test_bootstrap
unzip ~/git/aldersondrive_bazel/bazel-bin/bazel-distfile.zip
EXTRA_BAZEL_ARGS="--host_javabase=@local_jdk//:jdk" JAVA_HOME="/usr/local/jdk-1.8.0" BAZEL_JAVAC_OPTS="-J-Xmx2g -J-Xms200m" bash ./compile.sh

The resulting Bazel binary appeared to work in some simple testing involving cc_library, cc_binary, java_library, and java_binary.

Known issues/limitations:

• For the above to work, I had to add python to my PATH. (On OpenBSD, the Python binary is called python3.)

ln -s /usr/local/bin/python3 ~/bin/python

• Building a java_binary's deploy JAR fails because the singlejar tool fails to build. I intend to look into this issue next.

In file included from external/remote_java_tools_linux/java_tools/src/tools/singlejar/input_jar.cc:15:
In file included from bazel-out/host/bin/external/remote_java_tools_linux/_virtual_includes/input_jar/src/tools/singlejar/input_jar.h:27:
bazel-out/host/bin/external/remote_java_tools_linux/_virtual_includes/diag/src/tools/singlejar/diag.h:54:2: error: Unknown platform
#error Unknown platform
 ^

• Running Bazel requires a --host_javabase=@local_jdk//:jdk flag.

• Sandboxing is unsupported.

This change is part of the OpenBSD port in #10250.

[aldersondrive]

I've fixed the breakage; the tests pass now. PTAL.

(In case you're wondering: I can't run the tests on OpenBSD because the singlejar build error mentioned above means that the tests currently won't even build, let alone run.)

[ulfjack]

This is a pretty big change. I wonder if it could be broken up. Most of the changes are trivial, but we may need to look more carefully at the added C++ code.

[aldersondrive]

I would be okay with dividing up this PR, but I don't understand the interdependencies well enough to be confident of a good way to do so. Are you able to suggest one?

Regarding the added C++ code, it's mostly copy/pasted from the equivalent FreeBSD code, which is already in the repo. Thus, there's actually a lot less C++ code changing here than the Github interface suggests.

[hlopko]

Oh this is indeed too big for a PR. I'd split changes touching the client into one PR, one PR for the C++ toolchain configuration, one PR for the python semantics change, and maybe the rest.

Do you have a CI testing story figured out already? @philwo is your point of contact for that.

[hlopko]

I'll actually unassign folks from this PR and will wait for the smaller PRs. Thank you!

[aldersondrive]

Do you have a CI testing story figured out already? @philwo is your point of contact for that.

I've just filed bazelbuild/continuous-integration#876. (Earlier we briefly discussed FreeBSD CI also. There's already bazelbuild/continuous-integration#258 about that.)

Smaller PRs are on the way. Thanks!