Unresolved external symbol "FromConstructorTemplate..." linking on Windows about bitcore HOT 12 CLOSED

I have the same issue. I am not sure if Google v8 JavaScript engine is required?

from bitcore.

This feels more like a C++ name mangling mismatch, or something not defined under #windows that is defined under *nix. I haven't been able to track it down.

How would Google v8 JavaScript engine help resolve an issue in KeyModule? I doubt v8 does anything with encryption keys.

from bitcore.

Just to update, I was able to replicate this in my windows dev env this weekend.

from bitcore.

Feels like a v8/bitcore API mismatch.

from bitcore.

I am having this issue as well.. which is sadly a blocking issue for me trying to use this framework :-(

from bitcore.

When I first forked bitcoinjs I was having the same problem if you want to fix it once and for all this should do it...

replace this section of code

Handle<Value>
Key::New(const Arguments& args)
{
  if (!args.IsConstructCall()) {
    return FromConstructorTemplate(s_ct, args);
  }

  HandleScope scope;

  Key* key = new Key();
  if (key->lastError != NULL) {
    return VException(key->lastError);
  }

  key->Wrap(args.Holder());

  return scope.Close(args.This());
}

with :

Handle<Value>
CoinKey::New(const Arguments& args)
{
  HandleScope scope;

  // this was invoked as CoinKey() not new CoinKey()
  if (!args.IsConstructCall()) {
//    return FromConstructorTemplate(s_ct, args);

    const int argc = 1;
    Local<Value> argv[argc] = { args[0] };
    return scope.Close(s_ct->GetFunction()->NewInstance(argc, argv));
  }
  else{
    CoinKey* key = new CoinKey();
    if (key->lastError != NULL) {
      return VException(key->lastError);
    }

    key->Wrap(args.Holder());

    return scope.Close(args.This());
  }

}

This is all because of the missing FromConstructorTemplate() which is only used in the case of an invocation where you didn't use new...

Replacing that section of code will fix all your windows issues related to the key stuff in c++ (I think.. it's been a while since I did that fix)

from bitcore.

This seems significant: https://github.com/joyent/node/pull/2799.patch

It was a patch for src/node.h to add NODE_EXTERN to the FromConstructorTemplate declaration so that it would compile in Windows.

The FromConstructorTemplate helper function was removed from node_internals.h in this changeset: https://github.com/joyent/node/blob/110a9cd8db515c4d1a9ac5cd8837291da7c6c5ea/src/node_internals.h in July 2013

Bitcore currently references Node 0.10.26. The latest release branch of Node is 0.11.12. It looks like some major code churn occurred in Node in July 2013 related to changes in the V8 API.

Is there a particular reason why bitcore.js is built with such an old version of Node?

from bitcore.

op-sig: Thanks for the code! I get symbol not found on CoinKey, so I replaced CoinKey with Key and it now compiles on Windows. Here's my code:

Handle<Value>
Key::New(const Arguments& args)
{
  HandleScope scope;

  // this was invoked as Key() not new Key()
  if (!args.IsConstructCall()) {
//    return FromConstructorTemplate(s_ct, args);

    const int argc = 1;
    Local<Value> argv[argc] = { args[0] };
    return scope.Close(s_ct->GetFunction()->NewInstance(argc, argv));
  }
  else{
    Key* key = new Key();
    if (key->lastError != NULL) {
      return VException(key->lastError);
    }

    key->Wrap(args.Holder());

    return scope.Close(args.This());
  }
}

I'm now hitting a file concat error in the browser bundling step later in the build. I'll log a separate issue for that.

from bitcore.

Nice work guys on finding this :)

@dthorpe the reason that this and most all node packages use v0.10 is because the odd numbered versions of node are unstable. v0.10.26 is the latest stable build (last updated on Feb 18, 2014). v0.12 should be coming out any day now which should include those changes you mention from v0.11 and most repos will switch to it after a little while.

from bitcore.

@unusualbob ah. odd numbered builds unstable. did not know that. Thanks!

I wonder if this applies to odd numbered siblings, too?.... ;>

from bitcore.

No problem.. sorry about the CoinKey name change. I did a cut and paste out of my code and that's the name I switched the class to when creating this into a new library. I'm keeping an eye on the project and will kick in other help when I can.

I've been working on kind of a different route on bitcoinjs. I didn't like the monolithic build of the code and wanted to refactor into a set of useable npm libraries that build up to an eventual working copy of bitcoind.(It's also what I'd like to see happen to bitcoind core some day) In particular I didn't want to have to pull in the whole core just for keys.

My eventual goal is to have coinkey, coinsign, coincomm, each seperate npm packages to pull in and recreate bitcoind yet useable on their own. Will I get there? Maybe. I like to build projects as I build libraries to see where things fall apart so it's a little slower going. The current project is a super node so I'm mainly heads down in the networking code. I also ended up updating the wireshark disector here https://github.com/op-sig/bitcoin-wireshark-dissector so that I could get better test coverage.

One of the first projects was key generation and thus I did the fix above when I ran into that same problem. I was using the same private key to generate public keys for multiple coins. Probably the dumbest idea ever from a security standpoint but tinker we must.

from bitcore.

In particular I didn't want to have to pull in the whole core just for keys.

We have similar concerns. When you build bitcore for the browser, you can compile in only the parts that you need. Also, the node modules use lazy loading so they are only loaded into memory when you actually use them, ensuring minimal overhead.

from bitcore.