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

[Sakari369]

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 [email protected]

Fixed the compilation.

[bnoordhuis]

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.

[mauricedoepke]

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.

[TanninOne]

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]

@TanninOne Is there any workaround?

[TanninOne]

@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]

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]

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]

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]

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]

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

[shnooshnoo]

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

[Sakari369]

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 ..

[StefanStojanovic]

@Sakari369 did you get a chance to check this?

[Sakari369]

@Sakari369 did you get a chance to check this?

Hey! I did get this to work on Windows (and macOS) with Electron version 24.8.8, but that's as far as I had the bravery to update my Electron framework to, so not sure about newer versions.

But alas, I do not even know why it started working suddenly. And I don't have my Windows VM here right now, so I can't even check the configuration. I just remember being frustrated to having to battle this again, due to having to update my app and Electron framework, and just being almost close to giving up, then suddenly the thing compiled.

But that's all I can share .. don't have my Windows VM disk here right now, it's on a separate machine. Although dont think that would help, I seriously don't know what fixed it :P

I do know and have followed the conversation on the actual node-canvas repository, that they are close to releasing version 3, it might have fixed the building already ?

So maybe this can be closed ? Not sure, when I was updating, their transition to the new API was not finished.

[StefanStojanovic]

Thanks for the detailed answer. Since, from what I understood from your message, this is fixed now, I'd suggest closing the issue. If you notice it happening again you can always reopen it, or open a new one and reference this one in it.