package libunwind and libblocksruntime with honggfuzz

[zhenyudg]

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.

[stefanbucur]

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.

[fmeum]

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.

[zhenyudg]

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.

[stefanbucur]

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?

[zhenyudg]

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.

[stefanbucur]

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.