Upstream secp256k1-zkp API has changed about bitshares-core HOT 4 CLOSED

From @clayop on August 8, 2015 0:26

Related log

clayop@ubuntu:~/graphene$ git submodule update --init --recursive

...

Cloning into 'vendor/secp256k1-zkp'...
remote: Counting objects: 2907, done.
remote: Compressing objects: 100% (15/15), done.
remote: Total 2907 (delta 54), reused 49 (delta 49), pack-reused 2843
Receiving objects: 100% (2907/2907), 1.16 MiB | 1.37 MiB/s, done.
Resolving deltas: 100% (2069/2069), done.
Checking connectivity... done.
fatal: reference is not a tree: bd067945ead3b514fba884abd0de95fc4b5db9ae

...

Unable to checkout 'bd067945ead3b514fba884abd0de95fc4b5db9ae' in submodule path 'libraries/fc/vendor/secp256k1-zkp'
Failed to recurse into submodule path 'libraries/fc'

from bitshares-core.

Upstream secp256k1-zkp has rebased AND changed their API.

As a temporary fix, I have redirected the remote for the secp256k1-zkp submodule inside fc to point at our own copy: cryptonomex/fc@458b601

Those with already checked-out copies will want to manually edit their local remote to reflect this change, or otherwise clone fresh.

Ultimately we will want to update fc to work again with the new API in the latest upstream version, which I will assign to @bytemaster because he did the initial integration, I believe.

from bitshares-core.

From @clayop on August 10, 2015 18:10

Building works now.

from bitshares-core.

I have attempted upgrading to the new API and it is more trouble than it is worth. We will likely be stuck with this fork until there is a compelling reason upstream to overhaul fc ecc handling

from bitshares-core.