You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
proc-macro2 has been updated (see PR dtolnay/proc-macro2#296) which breaks our build.
After a make update a cargo update -p proc-macro2 --precise 1.0.28 is solving the immediate problem (needs to be done twice: once in the worker part and once in the enclave part)
A fast solution would be to include the cargo update --precise update into our make update but it's not the cleanest solution. This should be looked into a little bit deeper.
Yes, this is because our rust-toolchain is not recent enough for this. We could try updating the toolchain a little bit, but this might also break the build if the std-api deviates from sgx-tstd's as a consequence.
It hurts, but in our environment we probably neet to accept that we can't always do a plain cargo update.
We should then atleast keep the make update file up to date - because answering questions how to fix broken build takes longer than updating the make file. Is that acceptable?
(But I will try update rust toolchain and see if that works - will update on that one as soon as possible)
I did not see that we have a plain cargo update in the makefile - I would remove that definitely. Chances are high that it will break the build soon again.
We could try to get teaclave to update the toolchain and then go with that new release. otherwise: I think we will need the .lock file for the forseeable future and cargo update should not appear in the regular workflow
Activity
[-]cargo update breaks building[/-][+]cargo update breaks build[/+]clangenb commentedon Aug 31, 2021
Yes, this is because our rust-toolchain is not recent enough for this. We could try updating the toolchain a little bit, but this might also break the build if the std-api deviates from sgx-tstd's as a consequence.
It hurts, but in our environment we probably neet to accept that we can't always do a plain
cargo update.haerdib commentedon Aug 31, 2021
We should then atleast keep the make update file up to date - because answering questions how to fix broken build takes longer than updating the make file. Is that acceptable?
(But I will try update rust toolchain and see if that works - will update on that one as soon as possible)
clangenb commentedon Aug 31, 2021
I did not see that we have a plain cargo update in the makefile - I would remove that definitely. Chances are high that it will break the build soon again.
brenzi commentedon Aug 31, 2021
We could try to get teaclave to update the toolchain and then go with that new release. otherwise: I think we will need the .lock file for the forseeable future and cargo update should not appear in the regular workflow
brenzi commentedon Sep 13, 2021
Since a few days, our workaround will no longer work because of:
paritytech/substrate#9741
This is a severe showstopper.
Tried to motivate a teaclave upgrade:
apache/teaclave-sgx-sdk#360
Without this, I don't see a way to upgrade beyond paritytech/substrate@558a68f
clangenb commentedon Sep 13, 2021
I don't see any either, except for one I want to prevent at all costs because it might get ugly: patching and back-porting proc-macro2.
clangenb commentedon Jan 25, 2022
@haerdib can this be closed?
haerdib commentedon Jan 25, 2022
Yes, it can. It was solved with #603.
Thanks for pointing this out.