So, it looks like this issue can occur from several reasons.
Lack of --depth on the clone.... not that
submodule not pushed.....not that
git push --force .... looks like this is what happened, effectively deleting the tree bd067945ead3b514fba884abd0de95fc4b5db9ae from the commit history.
Vikram cloned this repo into
https://github.com/cryptonomex/secp256k1-zkp/commits/secp256k1-zkp, and you can see bd06794 in the commit history on May 29th. This commit is no longer a part of the
https://github.com/ElementsProject/secp256k1-zkp/commits/secp256k1-zkp?page=2 history and can't be checked out.
Currently the submodules are setup like:
cryptonomex/graphene -> cryptonomex/FC -> ElementsProject/secp256k1-zkp
How to fix:
Since vikram has already cloned secp256, probably the best way is to just update the fc repo to point to cryptonomex/secp256k1-zkp rather than the ElementsProject/secp256k1-zkp
However, this doesn't fix historical builds which are not very nice unless you go in and manually git clone and checkout specifically to bd06794
Or maybe talk with ElementsProject and see if you can get them to agree to never git push -f again... so we can trust using their commit trees directly.
Workaround to get project to build:
git clone
https://github.com/cryptonomex/graphene.gitcd graphene
git submodule update --init --recursive
cd libraries/fc/vendor/
rm -rf secp256k1-zkp/
git clone
https://github.com/cryptonomex/secp256k1-zkp.git cd secp256k1-zkp/
git checkout bd067945ead3b514fba884abd0de95fc4b5db9ae