| Age | Commit message (Collapse) | Author |
|---|
|
While for included libraries, it makes sense to have them with debug
symbols (after all, they are linked into a binary depending on it),
the toolchain binaries are just called, so there is no point in
building debug versions thereof.
|
|
Similarly to other third-party binaries, we should not care if they
are built in release or debug mode and as such we explicitly clear
the DEBUG flag.
|
|
Similarly to the proto compiler, this target is a third-party
binary and as such we do not care if it is built in release or
debug mode, so always clear the DEBUG flag.
|
|
As we only care about the result of proto targets, we do not care
if the proto compiler is built in release or debug mode, so always
clear the DEBUG flag for this binary.
|
|
... as this library is used by different export targets.
|
|
...together with its dependencies:
- boringssl dec0d8f681348af8bb675e07bd89989665fca8bc
- protobuf v29.0
- abseil 20240722.0
Also update the bootstrap command for ssl to account for the fact
that now also the crypto library has fully moved to C++ and the
location of its sources has changed.
|
|
|
|
|
|
|
|
|
|
Update also direct dependencies:
- boringssl b8b3e6e
- google_apis fe8ba05
- protobuf v27.2
Also update the bootstrap build description for crypto library.
Remove ssl patch for gcc-14 build as fix is now in upstream.
Remove bytestream.proto patch as fix is now in upstream.
Target utf8_range now taken only from protobuf, where it is first
defined.
For now, upb dependencies in grpc still taken from its own
third_party subdirectory, as it is still kept synchronized with
the corresponding tree in the corresponding protobuf version.
|
|
... to allow reproducible debug builds. Unfortunately, gcc does not support
such an option.
|
|
|
|
|
|
Those are trivial dependency updates without the need to
change the build description. The new versions now are
- fmt 11.0.2
- cli11 2.4.2
- zlib 1.3.1
|
|
|
|
... inheriting path from CC and shell defaults.
|
|
|
|
... as the default summarizer can make good use of that,
if provided.
|
|
|
|
|
|
... which is needed until this is merged:
https://boringssl-review.googlesource.com/c/boringssl/+/68227
|
|
... to simplify definition.
|
|
|
|
... that is no longer used since d762bfa1953933dfac0a29a74523c25719396b8c
|
|
|
|
- update boringssl to commit ae72a45
- update protobuf to v25.1
- update abseil to v20240116.0 (including patches)
Also add mirrors for third-party dependencies where known and
hashes correspond.
|
|
As we use chunking also for reducing storage, we have to consider
the overhead of block devices which is in the order of kB per file.
So our target chunk size should be at least 2 orders of magnitude
above this. This suggests to minimally aim for a chunk size of
128kB, a target size that also has the advantage the that maximal
chunk size associated with this size is 1MB which is still well
below the maximal transmission size of grpc allowing us to avoid
the streaming API.
As we're scaling everything up by a factor of 16, we also have
to increase the number of bits in the involved masks by 4. We use
this to also extend the window size by using the 2 most significant
octets. Following the advice of the paper proposing FastCDC to
spread out the ones roughly equally suggests 0x4444 as a suitable
value for the two most significant octets.
We also change the suggested extension of the remote-execution API
accordingly. As the precise parameters for FastCDC when announced
over the remote-execution APIs are still under discussion upstream,
we simplify the name to not mention the target size.
|
|
grpc is used in the toolchain defaults for proto servive libraries.
Still, it is typically built on its own, with its own toolchain,
flags, etc. Now, grpc, however has a public dependency on a the
rpc-status proto library, that the user may well use on their own,
however building in their own way which can yield conflicts. To solve
this, we hide the dependency on that proto library, as infrastructure
libs should not make assumptions on user-servicable libraries.
- First, we note that the dependency can be made a private one,
which already solves the conflict on header files (which will
essentially be the same, but might be defined in a different way).
- Next, we note that the library at linking basically only acts
as a default implementation; if the user provides their own
version of the rpc-status library, we should prefer that anyway.
As infrastructure is linked last, we have that default character
anyway; the only thing to do is to rename the library that no
staging conflict occurs.
|
|
This reverts commit 0db6f248a04f5a23102b4208c1f28b3633c6ef8a.
We have our own build description for lzma, hence we are likely not
affected by CVE-2024-3094. Nevertheless, we should not encourage the
use or distribution of an archive that contains a known backdoor.
Reverting this commit also points us to a mirror that is still
fetchable.
|
|
... and not directly used by our tool.
|
|
Now the curl URL API always fails to parse the empty string, so
our test was changed to reflect this.
|
|
|
|
|
|
|
|
Also updated the remote fetch repository, as the previous upstream
repository has since been archived.
|
|
Also updates the test-mixed-bootstrap script which must use the
explicit library version.
|
|
|
|
|
|
As a library, that target depends implicitly on the toolchain,
hence the already present export of "TOOLCHAIN_CONFIG", but also
the environment for using that toolchain. So, export "ENV" as well.
|
|
... so that they can be served and hence the corresponding
dependency can be absent.
|
|
The latest remote execution protocol version includes a blob splicing RPC and
allows for the negotiation of the used chunking algorithm between client and
server.
|
|
... of all produced binaries, including the intermediate
ones: protoc and grpc_cpp_plugin.
|
|
... glibc provides synchronization stubs for single-threaded
environments as weak symobls. When linking pthreads, these
weak symbols must be replaced by the strong symbols provided
by the pthread library. For dynamically linking pthreads,
this is done automatically. However, to support this for
static linking, we must ensure to link the whole archive.
|
|
As we patch that API, it also can implicitly depend on the
toolchain (and hence its config), if we use a compiled implementation
of patch. Making the TOOLCHAIN_CONFIG a flexible part of the config
allow to, again, build static binaries as usual.
|
|
|
|
... as it is used by various libaries that are exported independently.
|
|
The source archive of grp contains upwards symlinks (that do not
point outside the source directory). For a normal build this is
not an issue; we still can generate a git tree from this archive
and the parts we use of this archive never even touch a directory
containing an upwards symlink.
However, when just-mr desires to get this root from a just serve
instance, the tree would have to be synced to the remote-execution CAS
and hence the restriction applies that we only consider non-upwards
relative symlinks as first-class citizens.
Therefore, ignore all symlinks in this archive and this way, without
changing the actual build, obtain an easy-to-manage root.
|
|
... to allow target-level caching.
|
|
... as it is part of just-mr, which is an essential part of
the build system installation by now.
|
