Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

0.3.2 linker error on macOS #455

Closed
splix opened this issue Oct 20, 2019 · 18 comments
Closed

0.3.2 linker error on macOS #455

splix opened this issue Oct 20, 2019 · 18 comments

Comments

@splix
Copy link
Contributor

@splix splix commented Oct 20, 2019

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 neon-cli@0.3.1) 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

This comment has been minimized.

Copy link
Member

@kjvalencik kjvalencik commented Oct 20, 2019

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

This comment has been minimized.

Copy link
Contributor Author

@splix splix commented Oct 20, 2019

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: emeraldpay/emerald-vault-node@a9f9ef2

@kjvalencik

This comment has been minimized.

Copy link
Member

@kjvalencik kjvalencik commented Oct 20, 2019

The linked build log lists neon-build@0.3.1 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

This comment has been minimized.

Copy link
Contributor Author

@splix splix commented Oct 20, 2019

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

This comment has been minimized.

Copy link

@ernieturner ernieturner commented Oct 23, 2019

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

This comment has been minimized.

Copy link
Member

@kjvalencik kjvalencik commented Oct 23, 2019

@ernieturner 0.3.3 didn't address this, it fixed #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

This comment has been minimized.

Copy link
Member

@kjvalencik kjvalencik commented Oct 23, 2019

@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

This comment has been minimized.

Copy link

@ernieturner ernieturner commented Oct 23, 2019

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

This comment has been minimized.

Copy link
Member

@kjvalencik kjvalencik commented Oct 23, 2019

@ernieturner Right, I think pinning neon-cli@0.3.1 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

This comment has been minimized.

Copy link

@ernieturner ernieturner commented Oct 23, 2019

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

This comment has been minimized.

Copy link
Contributor Author

@splix splix commented Oct 23, 2019

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

@ernieturner

This comment has been minimized.

Copy link

@ernieturner ernieturner commented Oct 23, 2019

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

This comment has been minimized.

Copy link
Member

@kjvalencik kjvalencik commented Oct 23, 2019

@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

This comment has been minimized.

Copy link
Member

@kjvalencik kjvalencik commented Oct 23, 2019

@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

This comment has been minimized.

Copy link

@ernieturner ernieturner commented Oct 23, 2019

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

This comment has been minimized.

Copy link

@garyyu garyyu commented Nov 8, 2019

Same issue here.
And Switching back to 0.3.1 (npm install -g neon-cli@0.3.1) fixes the problem, thanks @splix

And how to fix with neon-cli@0.3.3? I have the build = "build.rs" and that build.rs file in my project, but same error.

@kjvalencik

This comment has been minimized.

Copy link
Member

@kjvalencik kjvalencik commented Nov 8, 2019

@garyyu The following things need to be in place.

  • neon-build@>=0.3.3
  • build = "build.rs" in Cargo.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

This comment has been minimized.

Copy link

@garyyu garyyu commented Nov 8, 2019

@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"]
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.