The temporary solution for binaries/tests that fully statically linked is to
link against `gflags` using `-Wl,--whole-archive`. This will no longer be
necessary, once Abseil ships with logging. Then we can (finally) use Abseil
flags and use a logging library that does not depend on a different flags
library.
PiperOrigin-RevId: 260705702
Change-Id: I8562faaff59f9c3e0e1d331186d2806d387438fb
This change moves away from a classical superbuild which downloads and builds
at build time. Instead, we now follow a "Fetch Content" workflow (available as
FetchContent in CMake 3.11+) and download dependencies at config time.
Rationale: Superbuild projects have the disadvantage that projects cannot
directly access their individual declared targets. This is not a problem with
regular libraries, as those are usually/supposed to be installed. With
Sandboxed API, this is not desirable, as it has dependencies like Abseil and
glog, which are almost always consumed by including their source tree using
add_subdirectory().
Fixes#10 and makes external embedding easier.
PiperOrigin-RevId: 260129870
Change-Id: I70f295f29a6e4fc8c330512c94b01ef10c017166
Also properly check status of send and use one-byte messages
to avoid issues with partial send, receive.
PiperOrigin-RevId: 258362495
Change-Id: I889b4699c100c80d15b129bf3a254f5442405bc2
PR_SET_PDEATHSIG is already issued for init process in SanitizeCurrentProcess
Same for setsid
PiperOrigin-RevId: 258142844
Change-Id: Iad9e94bd402d576c1b24caab0b03efc50e2df07e
* Move add_sapi_library() into a build defs file
* Override protobuf_generate_cpp() instead of naming it sapi_protobuf_generate_cpp()
* Factor out inclusion/find_package() calls of external dependencies
PiperOrigin-RevId: 258133422
Change-Id: Ibdbab0c735157eac0ed6122ab78f9d583c6905cc
* Implement add_sapi_library() similar to the Bazel rule
* Fix SuperBuild so that glog properly depends on gflags (needed for --logtostderr)
* Raise minimum required version of CMake to 3.10 (Ubuntu 18.04 LTS)
* Update sum sandbox policy to allow to get IDs and PIDs
PiperOrigin-RevId: 258124160
Change-Id: I64c2f8b27a3e842874adca9100bfce20a2b74f17
This change adds CMake targets for the actual Sandboxed API library. On its
own, this is not very useful, as there is no CMake equivalent to the
sapi_library() rule, yet. This will be worked on next.
PiperOrigin-RevId: 257177362
Change-Id: Ic06c945ab534b27306021d970a83691aae2e7e60
This change also tries to make the build more idempotent wrt to embedding projects.
PiperOrigin-RevId: 257177255
Change-Id: I291cd02840496db901f829e902623887f6e0eb10
When fetching exit status only lower 8-bits will be read.
Thus if getpid()&0xff == 0 the test can fail.
PiperOrigin-RevId: 257163766
Change-Id: I690c645fde33d1205578fd8873c5fc2974352ada
Since we use glog, we need to still rely on gFlags for as long as Abseil
logging is not yet released. To do this, we have the util/flag.h header in
SAPI, faking the newer style API of Abseil's flags library.
The rationale behind this is that glog includes/builds with gflags for
command line flag parsing and having more than one flag parsing library
active at the same time is asking for trouble.
PiperOrigin-RevId: 256982667
Change-Id: I9c5406cb9ef4458daebfec0b0713f9bddbf5c3ad
This makes it easier to work with the generated classes from client code.
PiperOrigin-RevId: 256132914
Change-Id: If7fb24a2cac998d2cdb04e8b627272064bf9793d
- made sure that define order is correct
- made sure to emit all defines related to target define
- fixed a bug where '(' was separated with macro name with space, this breaking the macro
PiperOrigin-RevId: 256129616
Change-Id: I636b13a72c6198fb59e8e387f42567c442b24352
Since the interface generator is invoked via a Bazel macro, it will be
expanded in the embedding context of the project using SAPI, so package access
needs to go through the full workspace root @com_google_sandboxed_api.
This change also modifies the CMakeLists.txt accordingly, as the "external"
subdirectory is no longer needed/wanted.
PiperOrigin-RevId: 255918784
Change-Id: I052c687509f65fef7f011a9d1a074a171595330f
If using Sandboxed API from an external Bazel WORKSPACE, dependencies can be
imported by declaring the repository and calling `sapi_deps()`:
```python
git_repository(
name = "com_google_sandboxed_api",
commit = "master",
remote = "https://github.com/google/sandboxed-api.git",
)
load(
"@com_google_sandboxed_api//sandboxed_api/bazel:sapi_deps.bzl",
"sapi_deps",
)
sapi_deps()
```
PiperOrigin-RevId: 255373664
Change-Id: I4c41ffc75e1ca95eb126702cb2d5cedb255191d5
This is tracked at
https://github.com/bazelbuild/bazel/issues/8672
and should only affect the tests for now.
PiperOrigin-RevId: 254943708
Change-Id: Iee18a3b8c1b570c7d04d09d533ecff33c3de7d57
We now require that Debian users install the `python3` and `python3-pip`
packages. This change lets the Python code search for `libclang.so`, which can
be located in different directories, depending on version, and is not found by
default otherwise.
Fixes#28
PiperOrigin-RevId: 254745872
Change-Id: Ia77680da2a3235c0a9518125676aa8a460e38e76
Starting with Bazel 0.27.0 --incompatible_depset_is_not_iterable became the
default.
Fixes#27
PiperOrigin-RevId: 254703981
Change-Id: I727e4b1c6a907c8794a00f61646c13ad8d4437b7
This code assumes, like Bazel's runfiles that the data dependency to access
exists in the same sub-tree as the binary:
WORKSPACE
+- sandboxed_api/sandbox2/examples/crc4
+- crc4bin
+- crc4sandbox
The code requires the directory structure to exist, so that in the example
above, crc4sandbox can use
GetDataDependencyFilepath("sandboxed_api/sandbox2/examples/crc4/crc4bin")
regardless of how it was called.
PiperOrigin-RevId: 251834480
Change-Id: I6470b62ce9b403297116481a0c17c070992f2e81
