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

Electron-rebuild canvas fails with nan 2.14.1, works with 2.14.0 #892

Open
Sakari369 opened this issue May 25, 2020 · 12 comments
Open

Electron-rebuild canvas fails with nan 2.14.1, works with 2.14.0 #892

Sakari369 opened this issue May 25, 2020 · 12 comments

Comments

@Sakari369
Copy link

Hey, I had trouble trying to figure out why running

npx electron-rebuild canvas

Failed with the following error on Windows 10 x64:

Canvas.obj : error LNK2001: unresolved external symbol "__declspec(dllimport) public: class std::shared_ptr<class v8::BackingStore> __cdecl v8::ArrayBuffer::GetBackingStore(void)

I reported the issue to to the node-canvas repository here: Automattic/node-canvas#1589

With more detail about the issue.
Somebody figured out nan 2.14.1 was the culprit, downgrading manually to nan 2.14.0 with

npm install nan@2.14.0

Fixed the compilation.

@bnoordhuis
Copy link
Member

The change in v2.14.1 that is responsible is 2c023bd.

You mention in the other issue that you're using electron 8.2.0. https://github.com/electron/releases claims it's shipping V8 8.0.426.27-electron.0 and that version supports the new API (it was added in 8.0.)

On the other hand... it also claims it's shipping Node.js v12.13.0 and that version of Node bundles V8 7.7 but I know electron probably does a frankenbuild of Node.js so I guess either is possible.

My hunch is that this is not a nan issue. It could be an electron issue per the above. At the very least, the development headers that electron ships claim it's V8 8.0 because that's what nan feature-gates on.

letmaik added a commit to letmaik/node-virtualcam that referenced this issue May 28, 2020
@mauricedoepke
Copy link

Had the same issue with nodejs 14 and electron 11.
Both claim to use v8 >= 8.

I manually edited the file from the commit 2c023bd in "./node_modules/canvas/node_modules/nan/nan_typedarray_contents.h"
to use the old api. That made it working for me.

mook-as added a commit to mook-as/rd that referenced this issue Mar 31, 2021
nan 2.14.1 does not appear to be compatible with the version of electron
we're using:

nodejs/nan#892
mook-as added a commit to mook-as/rd that referenced this issue Mar 31, 2021
nan 2.14.1 does not appear to be compatible with the version of electron
we're using:

nodejs/nan#892

Signed-off-by: Mark Yen <mark.yen@suse.com>
mook-as added a commit to mook-as/rd that referenced this issue Mar 31, 2021
nan 2.14.1 does not appear to be compatible with the version of electron
we're using:

nodejs/nan#892

Signed-off-by: Mark Yen <mark.yen@suse.com>
@TanninOne
Copy link

I'm pretty sure this is an error in how electron is built for windows, I have created a bug report here: electron/electron#29893
Going back to nan 2.14.0 won't work if you want to build for electron 13 or later as the old api got removed.

@wxfred
Copy link

wxfred commented Jul 8, 2021

@TanninOne Is there any workaround?

@TanninOne
Copy link

@wxfred tl;dr: So the solution currently would be to build modules with clang, which, to be completely honest, is a massive pita on windows atm.

Contrary to what I said earlier this isn't because of a bug in electron but because electron is built with clang now, which uses libc++ for its implementation of the stl.
If you build your native module with msvc or gcc, they will (by default) use their own implementation of the stl which isn't binary compatible which could then lead to crashes at runtime.
To avoid this libc++ changes the exported name of affected functions (adding a namespace called __1) which means the error happens at linktime instead of runtime.

The solution would be to build your native module with libc++, same as electron itself, but afaik the stl implementation is tightly tied with the compiler so you probably can't just use msvc with libc++, you have to use the compiler it's intended for.

node-gyp for example unfortunately isn't designed to let you use clang on windows.

This is where I am atm, I haven't yet managed to build my modules with clang and I'd rather make the switch to napi instead, seems like a better use of the time long term (plus I'd rather code than fight build systems)

@Sakari369
Copy link
Author

This is still an issue, when building node-canvas with electron-rebuild. Now faced this problem when installed electron 11.4.10, had to downgrade to nan 2.14.0 manually to fix the build.

@my2iu
Copy link

my2iu commented Oct 19, 2021

I'm using nan with Electron on 32-bit Windows, and the old "use 2.14.0" trick no longer works on the newest versions of Electron. I've tried building my modules using clang++. I could very well be wrong, but it looks like libc++ isn't supported on 32-bit Windows? I think Chromium might be building their own libc++ for 32-bit Windows. Does anyone know where to get a 32-bit Windows version of libc++?

I've seen posts elsewhere about people starting to migrate from nan to n-api, but I'm hesitant to rewrite everything only to find out it doesn't work either.

@devyetii
Copy link

devyetii commented Nov 21, 2021

Problem still here on Electron v16.0.1 with canvas 2.8.0 and nan 2.15.0 on Windows 10 (Here's the full thing original issue. Still showing the main error mentioned in this issue's body by @Sakari369. Really frustrated having to deal with all this hassle while only wanting to code a simple app using canvas.

@GitMurf
Copy link

GitMurf commented Nov 24, 2022

Problem still here on Electron v16.0.1 with canvas 2.8.0 and nan 2.15.0 on Windows 10 (Here's the full thing original issue. Still showing the main error mentioned in this issue's body by @Sakari369. Really frustrated having to deal with all this hassle while only wanting to code a simple app using canvas.

@devyetii I am having the same issue and have been troubleshooting for weeks now without able to figure out any workaround. Did you ever find a solution to this? So frustrating!

@GitMurf
Copy link

GitMurf commented Sep 27, 2023

This can now be closed with 🎉 Automattic/node-canvas#2235

@shnooshnoo
Copy link

I wanted to look into this issue, but apparently it is fixed now? @Sakari369 could you please confirm

@Sakari369
Copy link
Author

I wanted to look into this issue, but apparently it is fixed now? @Sakari369 could you please confirm

Will take a look as soon as I'm looking into the build process of my sw yet again, might take a while ..

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

9 participants