bazelbuild
package libunwind and libblocksruntime with honggfuzz
Currently, using honggfuzz + rules_fuzzing requires users to install libunwind-dev and libblocksruntime-dev. Users might also need to configure their bazel toolchains to support these dependencies.
I would prefer to see these dependencies packaged with rules_fuzzing, so that honggfuzz would build more hermetically. Preferably we could bazelify and build these dependencies from source; alternatively we can supply binaries.
How big of an issue is this in practice? I'm happy to consider alternative designs, but I would like to understand what are the pros/cons of each, especially in terms of complexity added to the codebase.
Speaking to the cons: libblocksruntime consists of two source files and two headers with a very simple Makefile. There is already a Google-provided BUILD file for libunwind here, which could likely be reused with a few modifications (mostly deletions). These could potentially be upstreamed to the Bazel Central Registry as they should be generically useful for other Bazel projects, which could help with maintenance.
How big of an issue is this in practice?
A change in my organization's Bazel toolchain setup broke compatibility and meant we couldn't fuzz until I figured out how toolchains worked and fixed the regression; edit: I ended up adding the dependencies' binaries to a patched version of rules_fuzzing to make the build hermetic instead of working with toolchains.
Supplying binaries would be restrictive, since they may not work on all platforms. If we provide BUILD rules for libunwind-dev and libblocksruntime-dev, are there other (transitive) dependencies that would need to be installed instead?
libblocksruntime shouldn't have transitive dependencies. libunwind might need implementations of certain functions on some architectures, but running libunwind on x86_64 shouldn't need transitive dependencies.
Thanks for this extra context. In this case, I'd be happy to review a PR that adds the missing build rules for these two libraries.