Repository navigation
Electron-rebuild canvas fails with nan 2.14.1, works with 2.14.0 #892
Description
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.
Activity
bnoordhuis commentedon May 25, 2020
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.
pin nan to 2.14.0 to avoid electron-rebuild issues
mauricedoepke commentedon Jan 30, 2021
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.
Packages: force nan 2.14.0
Packages: force nan 2.14.0
Packages: force nan 2.14.0
TanninOne commentedon Jun 25, 2021
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 commentedon Jul 8, 2021
@TanninOne Is there any workaround?
TanninOne commentedon Jul 9, 2021
@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 commentedon Jul 22, 2021
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 commentedon 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 commentedon 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 commentedon Nov 24, 2022
@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 commentedon Sep 27, 2023
This can now be closed with 🎉 Automattic/node-canvas#2235
shnooshnoo commentedon Nov 28, 2023
I wanted to look into this issue, but apparently it is fixed now? @Sakari369 could you please confirm
Sakari369 commentedon Nov 29, 2023
Will take a look as soon as I'm looking into the build process of my sw yet again, might take a while ..
StefanStojanovic commentedon Jul 17, 2024
@Sakari369 did you get a chance to check this?
Sakari369 commentedon Jul 17, 2024
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 commentedon Jul 18, 2024
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.