google
monero: Use latest builder
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
cc @binaryFate Can you please take a look here? This requires bumping the boost version, I presume.
cc @luigi1111 @moneromooo-monero or maybe one of you can take a look at the boost upgrade?
Just updating boost doesn't work unfortunately, I might have to try different versions or ask someone else who is more experienced.
Yes, the fix would be to bump boost. Currently boost is downloaded from && curl -s -L -o boost_${BOOST_VERSION}.tar.bz2 https://downloads.getmonero.org/libs/boost_${BOOST_VERSION}.tar.bz2 \. So to fix it, one would have to upload a different boost version there, or change the download source. (Among possibly other changes)
I did update it to 1.80 and it fails
#8 30.41 /usr/local/bin/../include/c++/v1/__config:13:10: fatal error: '__config_site' file not found
#8 30.41 13 | #include <__config_site>
#8 30.41 | ^~~~~~~~~~~~~~~
#8 30.41 1 error generated.
https://github.com/selsta/testrepo/actions/runs/9566788394/job/26372907450#step:3:843
I can also try newer or older versions.
Looks like boost 1.84 (or 1.81) is enough to avoid the deprecated c++11 code and the need to specify -DBOOST_NO_CXX98_FUNCTION_BASE.
To work around the missing __config_site. You can manually copy it for now as a temporary workaround. Just add this before downloading boost:
RUN cp /usr/local/include/x86_64-unknown-linux-gnu/c++/v1/__config_site /usr/local/include/c++/v1/
Also ./b2 ... stage would have to be replaced by ./b2 ... install.
If it works for you as well, and you agree with the changes, you can go ahead and create a new pull request against the master branch here.
It did build the docker image correctly, it failed to run it but that appears to be unrelated. Will open a PR with the changes.
I don't have a Google account unfortunately to sign the CLA. Can you add the commit to this PR, or should I ask someone else from the monero project to open the PR?
I'd say it is preferred if someone following the project is on the project's OSS-Fuzz auto_ccs and has signed the CLA. Otherwise it would be difficult to be notified of fuzz issues in the future, and also hard to submit patches to the project's config or build file.
rebased and re-opened as https://www.github.com/google/oss-fuzz/pull/12176 as myself for now, to unblock the clang bump