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

gdal-async is not compatible with Electron #28

Open
mmomtchev opened this issue Mar 10, 2022 · 16 comments
Open

gdal-async is not compatible with Electron #28

mmomtchev opened this issue Mar 10, 2022 · 16 comments
Labels
enhancement New feature or request

Comments

@mmomtchev
Copy link
Owner

mmomtchev commented Mar 10, 2022

  • Electron does not export zlib which GDAL uses
    • opening compressed files is to be disabled
  • Electron does not export OpenSSL which GDAL uses
    • https is to be disabled
  • Electron has a (build??) problem with the new GetBackingStore V8 API
    [Bug]: Link error for native c++ modules electron/electron#29893
    • a workaround is to be implemented
@mmomtchev mmomtchev added the enhancement New feature or request label Mar 10, 2022
@mmomtchev
Copy link
Owner Author

electron/electron#29893

@mmomtchev
Copy link
Owner Author

electron/electron#33230

@mmomtchev
Copy link
Owner Author

mmomtchev commented Mar 11, 2022

@tris-g, this will have to be postponed for 3.5.
There are a number of issues with Electron 17 which render a Windows build of a Node.js NAN addon impossible without sweeping changes - the most important being the fact that they impose using the clang compiler with libc++ instead of MSVC with STL - and the clang compiler is not supported by node-gyp - which means to redo the build system from scratch.
I will continue pestering them to find a solution to this problem - especially since many (most) other native addons are currently broken.
The 3.5 branch should work with Electron 16.x if:

  • You manually downgrade nan to 2.14.0
  • You manually delete the erroneous zlib.h headers from their distribution (they are stored in C:\Users\%USERNAME%\AppData\Local\node-gyp\Cache)

@mmomtchev
Copy link
Owner Author

@tris-g, I have added an Electron guide, including an example application

While Linux and macOS are relatively straightforward, Windows remains very problematic - you will have to either rebuild Electron from source or rebuild libc++ - which is still considered experimental - on Windows

@zsunpl
Copy link

zsunpl commented Jul 5, 2022

Hello Momtchev, I follow your electron example, I'm a little bit confused, to use gdal-async in windows 10, do I need to rebuild electron from source using visual studio, or just rebuild libc++ using visual studio? My electron version is 19.0.7.
Thanks a lot! @mmomtchev

@mmomtchev
Copy link
Owner Author

You need to rebuild both - unless you can find a binary of libc++ that works with visual studio. This build is not for the faint of heart.

@zsunpl
Copy link

zsunpl commented Jul 9, 2022

Hello Momtchev, I rebuilt electron 19.0.1 and libc++ on windows using clang, And then I follow your tips which provided in electron examples. However I still got link error——unresolved external symbol of 'GetBackingStore'。Did I miss something?
By the way,Since I just want a working version of "gdal-async+electron", If I downgrade electron under 13, nan under 2.14.0, can I make it work? Thank you so much!

@mmomtchev
Copy link
Owner Author

You didn't build it with libc++ - it is about libc++ not about clang. If you were to find a method to build with Visual Studio and libc++ - it would work

@zsunpl
Copy link

zsunpl commented Jul 11, 2022

Do you mean built libc++ with Visual Studio using clang compiler, and then link gdal.node with that libc++.lib?

@mmomtchev
Copy link
Owner Author

gdal.node cannot be linked with node unless it has been built with libc++ because this is what Electron uses on Windows.

If you can build libc++ with Visual Studio - it might be possible to link it - but normally libc++ has better clang support - and even this is somewhat experimental. Alas, they still do not distribute binaries. Refer to electron/electron#29893 for more information, the subject has been extensively debated in the Electron community and goes far beyond gdal-async - all Nan modules are impacted - including for example node-canvas - which is the main subject of contention.

@zsunpl
Copy link

zsunpl commented Jul 14, 2022

@mmomtchev After fighting the compilation of gdal-async for several days, I decided to give up.
Now I just want a working version of "gdal-async + Electron". Somebody said Electron under 13.0, nan under 2.14.0 didn't affect by the bug of electron/electron#29893. which version of gdal-async should I use ? Can you give me some hints? Thank a lot!

@mmomtchev
Copy link
Owner Author

Only the Electron version matters - all versions of gdal-async should work

@zsunpl
Copy link

zsunpl commented Jul 14, 2022

Only Electron? It has nothing to do with nan? Somebody said nan after 2.15.0 use "GetBackingStore" api which is defined in new version of v8 which is integrated in electron. BTW which version of electron under 13.0.0 is best suitable for gdal-async?

@mmomtchev
Copy link
Owner Author

Nan has a conditional compilation depending on the V8 version - which is determined by the Electron version. Get the last one before the new GetBackingStore.

@zsunpl
Copy link

zsunpl commented Jul 18, 2022

@mmomtchev
Hello mmomtchev .
I'm new to Electron and gdal-async, I keep fighting to integrate "gdal-async + Electron" ...
I tried to downgrade electron to v11.0.4 and NAN to v2.14.0, then I got compiler errors like "C2039 Address: is not member of v8::internal. I guess the version of nan isn't match the v8 version which electron used, is that right?
I saw there are pre-built version of gdal.node provided in release. Can I use the pre-built version of gdal.node in electron to avoid the electron-rebuild process which is a painful job?
Thank you so much!

@mmomtchev mmomtchev removed this from the 3.5 milestone Dec 21, 2022
@mmomtchev
Copy link
Owner Author

This continues to be a huge problem on Windows - where Electron is built with a different C++ runtime from Node.js - and cannot be cleanly solved until #35

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

No branches or pull requests

2 participants