Neon: 0.3.2 linker error on macOS

[splix]

When I try to build with neon-cli 0.3.2 on macOS it fails with:

ld: warning: cannot export hidden symbol compiler_builtins::mem::memcpy::h89bf2c29275db9b6 from /var/folders/09/3ccx9hvj499_767y34mtcr900000gn/T/rustc5SpE5s/libcompiler_builtins-4c0e14a54ecf951d.rlib(compiler_builtins-4c0e14a54ecf951d.compiler_builtins.dcjs62au-cgu.0.rcgu.o)
          ld: warning: cannot export hidden symbol compiler_builtins::mem::memmove::hb03f562604dc3076 from /var/folders/09/3ccx9hvj499_767y34mtcr900000gn/T/rustc5SpE5s/libcompiler_builtins-4c0e14a54ecf951d.rlib(compiler_builtins-4c0e14a54ecf951d.compiler_builtins.dcjs62au-cgu.0.rcgu.o)
          ld: warning: cannot export hidden symbol compiler_builtins::mem::memset::h1f53dc51033b23d1 from /var/folders/09/3ccx9hvj499_767y34mtcr900000gn/T/rustc5SpE5s/libcompiler_builtins-4c0e14a54ecf951d.rlib(compiler_builtins-4c0e14a54ecf951d.compiler_builtins.dcjs62au-cgu.0.rcgu.o)
          ld: warning: cannot export hidden symbol compiler_builtins::mem::memcmp::hc5ebea53cd23af68 from /var/folders/09/3ccx9hvj499_767y34mtcr900000gn/T/rustc5SpE5s/libcompiler_builtins-4c0e14a54ecf951d.rlib(compiler_builtins-4c0e14a54ecf951d.compiler_builtins.dcjs62au-cgu.0.rcgu.o)
[...]
Undefined symbols for architecture x86_64:
            "v8::Isolate::ThrowException(v8::Local<v8::Value>)", referenced from:
                _Neon_Error_Throw in libneon_runtime-0d1b50c0de5edd79.rlib(neon.o)
                _Neon_Error_ThrowErrorFromUtf8 in libneon_runtime-0d1b50c0de5edd79.rlib(neon.o)
            "v8::Value::IsNumber() const", referenced from:
                _Neon_Tag_IsNumber in libneon_runtime-0d1b50c0de5edd79.rlib(neon.o)
            "v8::HandleScope::CreateHandle(v8::internal::Isolate*, v8::internal::Object*)", referenced from:
                _Neon_Class_HasInstance in libneon_runtime-0d1b50c0de5edd79.rlib(neon.o)
[...]
          ld: symbol(s) not found for architecture x86_64
          clang: error: linker command failed with exit code 1 (use -v to see invocation)

with [...] I skipped similar lines, but I can provide full trace.

Switching back to 0.3.1 (npm install -g [email protected]) fixes the problem.

Tried with

• NodeJS v10.15.3, v10.16.3 and v12.12.0.
• rustc 1.38.0 (625451e37 2019-09-23)

[kjvalencik]

Has neon-build also been upgraded to 0.3.2? There was a breaking change that moved some rustc flags required for macOS from the cli to the build script.

https://github.com/neon-bindings/neon/blob/master/RELEASES.md#potentially-breaking

[splix]

yes, everything was updated to 0.3.2.

You can see it here: https://travis-ci.org/emeraldpay/emerald-vault-node/jobs/600377027 (ignore all other failed jobs in that build, they are related to #454)
Changes for that build are simple change of the version: https://github.com/emeraldpay/emerald-vault-node/commit/a9f9ef2fdfaf

[kjvalencik]

The linked build log lists [email protected] and not 0.3.1. Although, the commit includes the correct version in Cargo.toml and Cargo.lock.

Are you able to try again or see what's pulling the old version?

https://travis-ci.org/emeraldpay/emerald-vault-node/jobs/600377027#L232

[splix]

Oh, that's weird. Good catch, I didn't notice.
Could be some caching, but I have the same issue on my local macos machine. I will try to figure out what's going on.

[ernieturner]

I've updated all dependencies to 0.3.3 but this error is still happening for me. Here's the build log which shows

Compiling neon-build v0.3.3
...
Compiling neon-sys v0.3.3
Compiling neon-runtime v0.3.3
Compiling neon v0.3.3

I'm going to try to force downgrade back to 0.3.1 to see if that fixes it.

[kjvalencik]

@ernieturner 0.3.3 didn't address this, it fixed https://github.com/neon-bindings/neon/issues/456.

I have been unable to re-produce this. Was this issue new for you in 0.3.2? Any tips for reproducing? Thanks!

[kjvalencik]

@ernieturner I think the issue is that recrypt-node-binding specifies the crate type as dylib. This was in a previous version of the neon-cli template and is incorrect. It should be cdylib. I think this is preventing the build.rs flags from being used.

[ernieturner]

Sorry, I wasn't trying to say that I thought 0.3.3 would fix it, I just wanted to add some other data points to this ticket and figured I'd go to the latest version.

I just came across this because I was trying to update another dependency and I had ~0.3 for both neon and neon-build within my Cargo.toml so when I ran cargo update it bumped from 0.3.0 to 0.3.3. I didn't do any other code changes but when I tried to compile I got the error above. So unfortunately I don't really have much to go on for reproducibility.

One thing I did try which may not be useful is that I can upgrade the neon and neon-build Rust libraries to 0.3.3 as long as I leave the neon-cli NPM dependency back at 0.3.1. That seems to correlate to your comments above about what was changed.

[kjvalencik]

@ernieturner Right, I think pinning [email protected] would also resolve the issue. A couple of build flags were moved from the cli to build.rs. As mentioned above, this is interacting poorly with a previous bug in the template that created neon libraries as dylib instead of cdylib. I'll be very interested in hearing if 0.3.3 works for you after switching the crate type.

Thanks!

[ernieturner]

Changing the create-type to cdylib didn't seem to fix anything locally. I pushed up that change to see what Travis ends up with, but their OSX backlog is pretty bad right now so it probably won't run for a few hours.

[splix]

It stopped to reproduce on my project. I suspect it was something with caching, or cdylib.

[ernieturner]

Yep, no difference in the error with the changes to crate-type. I'm going to downgrade the CLI for now just to get this to pass but I'd be up for trying other changes if there's anything that would help figure this out.

[kjvalencik]

@ernieturner Looking at the logs, the link args are definitely missing (no -undefined or dynamic_lookup), but I can't immediately think of a reason why.

If you get it to build, I'd be curious what the link final cc link command looks like.

[kjvalencik]

@ernieturner Oh! I think I see the issue. There's no build.rs file. It was previously only required for Windows, but now it's required for both Windows and macOS.

https://github.com/neon-bindings/neon/blob/master/RELEASES.md#potentially-breaking
https://github.com/neon-bindings/neon/blob/master/test/dynamic/native/build.rs
https://github.com/neon-bindings/neon/blob/master/test/dynamic/native/Cargo.toml#L6

FYI, the core team is in discussion of giving breaking changes far more scrutiny. This builds args move was considered fairly minor, but has broken a few different builds.

[ernieturner]

That does fix it! Thanks for the help @kjvalencik, I appreciate it.

Also, as an unrelated side note, I wanted to also say thanks for your work getting this project back up and running. There was a time there when I wasn't sure what the future of this project was going to be so it's really nice to see more activity here.

[garyyu]

Same issue here.
And Switching back to 0.3.1 (npm install -g [email protected]) fixes the problem, thanks @splix

And how to fix with [email protected]? I have the build = "build.rs" and that build.rs file in my project, but same error.

[kjvalencik]

@garyyu The following things need to be in place.

• neon-build@>=0.3.3
• build = "build.rs" inCargo.toml`
• build.rs running neon-build
• crate-type = ["cdylib"] in Cargo.toml

Crate type might be the issue since this was previously incorrect in the neon-cli new project template.

[garyyu]

@kjvalencik thanks :-)

The cdylib fix my problem, indeed I was using dylib (refer to https://github.com/gottstech/grinwallet-nodejs/blob/master/native/Cargo.toml#L14)

I need change it to:

crate-type = ["cdylib"]