Workaround for Boost compilation error with Clang 18 and libc++ in ossfuzz buildpack-deps #15713
Conversation
| @@ -59,26 +62,19 @@ RUN apt-get update; \ | |||
| pygments-lexer-solidity \ | |||
| pylint \ | |||
| requests \ | |||
| tabulate \ | |||
| z3-solver; | |||
There was a problem hiding this comment.
Z3 is already installed from source in the steps below, so this is unnecessary. I also removed CMake, as it is already included in the base image.
There was a problem hiding this comment.
This is the python package of Z3, which is unrelated to the Z3 binary built below.
However, if it can be removed without anything breaking, that it's good to remove it :)
There was a problem hiding this comment.
Yeah, it is not used by any CI job based on the ossfuzz image as far as I know. The chk_proofs which is the job that runs the script mentioned here: #15551 (comment) uses the Ubuntu 24.04 image and it is not run by ossfuzz. This is why I'm also wondering if all the smt stuff is really needed here, or if we should just remove it from this image.
There was a problem hiding this comment.
Ok, I updated Z3 and CVC5, but I kept the removal of the z3-python, I don't think it is relevant for this image. Because it is required by the tests under test/formal, which indeed uses the z3 python bindings, but I believe the fuzzer does not run such tests. Maybe there are more things that we could cleanup as well.
This comment was marked as outdated.
This comment was marked as outdated.
| LABEL version="8" | ||
| # FIXME: Workaround for Boost 1.83.0 build failure when using Clang 18 (default since https://github.com/google/oss-fuzz/pull/11714) | ||
| # See: https://github.com/google/oss-fuzz/blob/5a9322260c4c66e7eb3e5d922b9fee6621ffd8da/projects/solidity/Dockerfile#L17C1-L18C139 | ||
| FROM gcr.io/oss-fuzz-base/base-builder@sha256:19782f7fe8092843368894dbc471ce9b30dd6a2813946071a36e8b05f5b1e27e AS base |
There was a problem hiding this comment.
Hey @bshastry do you see any problem in switch images here?
There was a problem hiding this comment.
Soft approve. Let's wait until end of week for @bshastry to chime in regarding the base image change.
Sure, better to have a response from him on that. Also, honestly, we could maybe even cleanup a bit more our current image. Do we fuzz with smt enabled? |
|
If you end up not removing the solvers, then they should be updated as was done for other Docker images in #15551. |
r0qs
force-pushed
the
fix-ossfuzz-build
branch
2 times, most recently
from
61b3046 to
2278b26
Compare
r0qs
force-pushed
the
fix-ossfuzz-build
branch
2 times, most recently
from
4d41e5d to
7d91183
Compare
r0qs
force-pushed
the
fix-ossfuzz-build
branch
from
7d91183 to
baadd1a
Compare
|
|
|
LGTM if build passes :-) |
This PR implements the same workaround applied by the ossfuzz maintainers to the Solidity ossfuzz setup:
https://github.com/google/oss-fuzz/blob/5a9322260c4c66e7eb3e5d922b9fee6621ffd8da/projects/solidity/Dockerfile#L17-L18
It replaces
base-clangwithbase-builder, the same image used by ossfuzz, that utilizes Clang 15. This change allows us to continue running our instance in CI until a fix for the main issue is available.Workaround for: #15711