E.g. a failed `KillSandboxee` for a timeout would already set the exit status code while there could be an external kill pending at the same time which would try to `KillSandboxee` again and thus set exit status code again.
PiperOrigin-RevId: 448464765
Change-Id: Ic5744a576c4255504bfb1d5c4f33253b5bb32b6f
This should make multithreaded sandboxees that exec (or send `SIGKILL`) behave more reliably.
PiperOrigin-RevId: 447458426
Change-Id: Ifdace340462199dc24c8cdf25d589ef6b24991e1
Instead of calling `google::InitGoogleLogging()` directly, introduce an
indirection via a new utility library. After this change, Sandboxed API
should consistently use `sapi::InitLogging()` everywhere.
For now, `sapi::InitLogging()` simply calls its glog equivalent. However,
this enables us to migrate away from the gflags dependency and use Abseil
flags. Once a follow-up change lands, `sapi::InitLogging()` will instead
initialize the google logging library with flags defined from Aseil.
Later still, once Abseil releases logging, we can then drop the glog
dependency entirely.
PiperOrigin-RevId: 445363592
Change-Id: Ia23a7dc88b8ffe65a422ea4d5233bba7bdd1303a
Also revert the `.bazelversion` file again, as this will enforce a fixed
version, not a minimum version, which does not work well with our BazelCI.
PiperOrigin-RevId: 444178761
Change-Id: Ib6d1d126d850640ca7d692543784263790b8c418
Internally, we rely on clang-tidy to warn about using deprecated declarations.
And for using deprecated declarations within SAPI itself, we should not warn.
Drive-by:
- Fix warning in `mounts_test.cc`
PiperOrigin-RevId: 443634512
Change-Id: I7ef66f0ba77201026490baab07766510c1c55c6a
`BUILD_TESTING` is a CMake provided option and we should use similar naming,
just like how Abseil does it.
- `SAPI_ENABLE_TESTS` -> `SAPI_BUILD_TESTING`
- `SAPI_ENABLE_CONTRIB_TESTS` -> `SAPI_CONTRIB_BUILD_TESTING`
- `SAPI_ENABLE_EXAMPLES` -> `SAPI_BUILD_EXAMPLES`
Drive-by:
- Fix option name in GitHub action
PiperOrigin-RevId: 443305932
Change-Id: Ice2b42be1229a0f9ae7c2ceda9ce87187baf22c4
Including the `CTest` modules ensures that the `BUILD_TESTING` option is
defined and automatically calls `enable_testing()` if needed. It does not
change the default or introduce any dependencies on its own.
This follows what Abseil already does in their top-level `CMakeLists.txt`.
PiperOrigin-RevId: 443305646
Change-Id: If067c17470f497437c7748aab4aab5227c26e84f
Bazel's `Runfiles::Create()` does not actually need a value for `argv0` in
order to find runfiles for the current `cc_binary`.
- Rename `runfiles.cc` to `runfiles_nobazel.cc`
PiperOrigin-RevId: 443061178
Change-Id: I31e16d69d24aecbc403f9407fc08c615bb1e8f9f
The corresponding command-line option `sapi_isystem` will be ignored for
compatibility.
PiperOrigin-RevId: 439806387
Change-Id: I8ad6d7feed2fba5fca9940281f03cfc757ada5be
This makes `sapi_library()` more compatible with Bazel's native `cc_library()`
rule.
PiperOrigin-RevId: 439512659
Change-Id: If731f600d56db56f78d2897e0c41a200daa93b75
This should fix the build on Debian 10 with LLVM 11.
- Keep order of files to look up in `ls` invocation
- Use `--start-group`/`--end-group` linker options
- Drive-by: use `splitlines()` instead of manual `split("\n")[:-1]`
PiperOrigin-RevId: 439248079
Change-Id: I919bb292ac8a5f514431aa004345f1c6478b1cc9
This change introduces an experimental `generator_version` attribute to the
`sapi_library()` rule. Version `1` will select the current interface
generator, which is based on libclang and Python. Setting the attribute to
version `2`, will select the newer interface generator written in C++ that
uses a full clang compiler frontend for parsing. Both emit equivalent header
output, differences in parsing and/or edge cases notwithstanding.
The default, as of now, is still the old version `1` generator.
Note: CMake allows to select the new interface generator globally by setting
`SAPI_ENABLE_GENERATOR`.
PiperOrigin-RevId: 438765013
Change-Id: I69c49a6bcf1751724edb0bce5c3b2beea2097138
This adds a workspace rule that inspects the current system first and
downloads a suitable version of LLVM/Clang from GitHub if it can't
find one. In the latter case, the necessary parts are build from source,
which can take a while (~10-15m, depending on the build machine).
In order to be found, LLVM/Clang system libraries must be version 11
or higher. On Debian/Ubuntu, install `llvm-13-dev` and `libclang-13-dev`.
The new `llvm_config.bzl` implements this logic. It is loosely based on
upstream's https://github.com/llvm/llvm-project/blob/main/utils/bazel/configure.bzl.
Note that due to the way Bazel separates local repositories, we have to
duplictate some of this code.
PiperOrigin-RevId: 438759950
Change-Id: Ia65f473b4cdef6507e3816bf09794ea10963d87a
This will allow us to experiment with (and subsequently migrate to)
changes to the generated API, possibly incompatible ones.
This change should be a no-op for current builds, as there is only
a single version of Sandboxed API.
PiperOrigin-RevId: 438003314
Change-Id: Ia23ea4360bee0227692d9f5220ab20d85f089ba7
This change merges the internal version of `sapi.bzl` with the external version again:
- Add more docstrings to the various macros
- Skip creation of `.isystem` file, get info from toolchain instead
PiperOrigin-RevId: 437730588
Change-Id: I6f670d32e3d7177a6a160fd24cbee6f8f3ca9503
This fixes the main issue (#118) with stack traces on Fedora, which uses a
`/lib64` and `/usr/lib64`.
PiperOrigin-RevId: 437717858
Change-Id: I6986aa84c2be57ae1d9f8d0cb9b508768d27f1c1
