Use [`direct_headers`](https://bazel.build/rules/lib/CompilationContext#direct_headers)
from the Bazel/Blaze compilation context instead of _all_ transitive headers.
For the clang based generator, this means we don't try to parse
`textual_headers`, which will fail (they are by definition not
stand-alone, after all).
PiperOrigin-RevId: 431899423
Change-Id: I7a9dfa0dd93eba14b506b0e7ca6db3ed59b55dd6
This will speed up our builds a bit and prevent unnecessary network traffic.
Setup according to the documentation for the `actions/cache@v2` action:
https://docs.github.com/en/actions/using-workflows/caching-dependencies-to-speed-up-workflows
Currently caching the `${{github.workspace}}/_deps` directory, as used by CMake.
Cache keys look like this: `ubuntu-20.04-clang11` (`${{matrix.os}-${{matrix.compiler}}${matrix.compiler-version}}`)
PiperOrigin-RevId: 431895214
Change-Id: I4ecac7c00eec8516f85f45aa2220303b811b2389
The default limit for recent versions of Clang is 256 which is less than the
number of syscalls in our syscall tables (around 340). This change increases
this limit to an arbitrary 768.
PiperOrigin-RevId: 429258387
Change-Id: I4927eee78edc8aaa2a758b29811d02326e5aa953
Linking glibc in fully static mode is mostly unsupported. While such binaries
can easily be produced, conflicting symbols will often make them crash at
runtime. This happens because glibc will always (try to) load some dynamically
linked libraries, even when statically linked. This includes things like the
resolver, unicode/locale handling and others.
Internally at Google, this is not a concern due to the way glibc is being built
there. But in order to make all of our tests run in the open-source version of
this code, we need to change strategy a bit.
As a rule of thumb, glibc can safely be linked statically if a program is
resonably simple and does not use any networking of locale dependent
facilities. Calling syscalls directly instead of the corresponding libc
wrappers works as well, of course.
This change adjusts linker flags and sandbox policies to be more compatible
with regular Linux distributions.
Tested:
- `ctest -R '[A-Z].*'` (all SAPI/Sandbox2 tests)
PiperOrigin-RevId: 429025901
Change-Id: I46b677d9eb61080a8fe868002a34a77de287bf2d
In the case of decompression, we are using the same chunk of memory
twice. The first is to obtain the size of decompressed data, and
the second is to decompress it. In the current code, we are copying
the chunk of memory twice. The memory doesn't change between
the calls, so there is no point in copying it over and over.
Let's synchronize memory only during first call.
- `SKIP_BUILD_RPATH` needs to be set per directory (not allow-listed for
`INTERFACE` properties)
- Use correct name for position independent code
- `-pie`/`-fPIE` will only propagate fully on 3.14+
PiperOrigin-RevId: 428986266
Change-Id: Idf9d7fc184fbeec8ec1b77505246e262d9b8d880
- Link `zipe.c` statically (safe)
- Update policy to allow any use of `stat()`
PiperOrigin-RevId: 428971638
Change-Id: Ib0f5f496ea2389582986b41a8830592e6c1d4390
This adds a first basic test to be run using GitHub Actions on push and pull
request for the CMake build (internally we run everything on Bazel/Blaze).
The Ubuntu runners are implemented as full VMs, so we can run tests directly.
In order to run Sandboxed API/Sandbox2 tests inside a container, it must be
started as privileged, unconfined and retain its capabilities.
Since GitHub does not support modifying the Docker invocation for container
based workflows, we need to manually run the `docker` command.
Until #118 is fixed, this change makes GitHub ignore the test failure on
Fedora.
PiperOrigin-RevId: 428485354
Change-Id: I6b55c5441c4c27b018d19498d2296c7d3da65846
Instead of C++17 structured bindings, use a plain `const auto&` and annotate
arguments with comments instead.
We still support Clang 6.0, as that is the compiler that ships with Ubuntu
18.04 LTS by default.
PiperOrigin-RevId: 428016214
Change-Id: I3a43b2d47c6825ac4425d22018750282cfe23c1b
This fixes a couple of tests in the open source version of the code.
Internally, since we are using a different ELF loader, the page offset
will always be zero. Hence we never notices this was broken.
PiperOrigin-RevId: 427996428
Change-Id: I44c5b5610b074cf69b9f0c5eeb051be50923e351
Note that `//sandboxed_api/sandbox2:stack_trace_test` may still fail for
unrelated reasons, as we are linking libc statically, which is brittle. A
follow-up change will fix this.
PiperOrigin-RevId: 427175045
Change-Id: Ifb5ec2ac3d60f4bcc9708f26c834c83b75e769d7
