Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix OpenSK build problem (nightly version) #7177

Merged
merged 2 commits into from
Jan 24, 2022

Conversation

kaczmarczyck
Copy link
Contributor

The bug occured first in our GitHub workflow, and was then automatically reported. OpenSK pins the nightly for its builds, and that is necessary for the build script here as well.

@kaczmarczyck
Copy link
Contributor Author

Note that this bug was already (almost) fixed in #6648, but a recently introduced newer nightly started to be incompatible.

@kaczmarczyck
Copy link
Contributor Author

@catenacyber Can you double check if this is sound, or was there a specific reason you omitted the nightly version in your PR?

@catenacyber
Copy link
Contributor

Can you double check if this is sound, or was there a specific reason you omitted the nightly version in your PR?

CI seems unhappy...
I guess oss-fuzz needs a newer nightly version, (likely the one with LLVM 13 from August if I remember correctly must be kind of a breaking change...)
Even if you do not need the latest for now, I guess at some point, you will need to upgrade...

There may be a workaround I do not think of right now... You can try to reproduce locally the check_build failure to investigate

@catenacyber
Copy link
Contributor

You should also invetigate why rustc sees llvm_asm became an unknown feature since 20th of January

@catenacyber
Copy link
Contributor

cf rust-lang/rust@a34c079

@kaczmarczyck
Copy link
Contributor Author

Ah right thanks, I had something in the back of my mind, but it worked locally. I think I found a compiler version that is both

  • recent enough for LLVM
  • old enough to compile OpenSK

Deprecations like with llvm_asm are the reason we are pinning a compiler version. This particular problem occured in one of our third party dependencies. I don't think we want to carry the maintenance burden to upgrade third party code to new compilers whenever ours stops being supported by OSS-Fuzz.

Are we the only Rust project that pins compiler version? Is there another workaround for the inevitable next breakage?

@catenacyber
Copy link
Contributor

Are we the only Rust project that pins compiler version?

I think so

Is there another workaround for the inevitable next breakage?

None that I know of, just update code and dependencies to work with the latest nightly...
Often, there are warnings about things before they get deprecated, so you can get rid of those before they break.

@DavidKorczynski DavidKorczynski merged commit 7bc43df into google:master Jan 24, 2022
DonggeLiu pushed a commit that referenced this pull request Feb 3, 2022
* exports a more specific nightly version

* trying intermediate compiler version to compromise
MartinPetkov pushed a commit to MartinPetkov/oss-fuzz that referenced this pull request Aug 15, 2022
* exports a more specific nightly version

* trying intermediate compiler version to compromise
@kaczmarczyck kaczmarczyck deleted the opensk-nightly-version branch March 8, 2023 09:58
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants