Error "is not Win32 application" when use electron-builder

Question

Error "is not Win32 application" when use electron-builder

zivlakmilos opened this issue a year ago · comments

Milos Zivlak commented a year ago

SerialPort Version

10.5.0

Node Version

v16.14.2

Electron Version

23.2.0

Platform

Microsoft Windows NT 10.0.19045.0

Architecture

x64

Hardware or chipset of serialport

No response

What steps will reproduce the bug?

Dev machine: Linux zivlak 6.1.1-arch1-1 #1 SMP PREEMPT_DYNAMIC Wed, 21 Dec 2022 22:27:55 +0000 x86_64 GNU/Linux
Test machine: Microsoft Windows NT 10.0.19045.

Electron builder version: 23.6.0
Electron builder target: portable x64

Create electron project
Import SerialPort
Build project using electron-builder on Linux machine
Copy .exe file to windows machine and run it

What happens?

Uncaught Error: \\?\C:\Users\ZI\AppData\Local\Temp\3c0cfb43-c0d6-41df-8ecf-ce6623539fad.tmp.node is not a valid Win32 application.
\\?\C:\Users\ZI\AppData\Local\Temp\3c0cfb43-c0d6-41df-8ecf-ce6623539fad.tmp.node
    at process.func [as dlopen] (node:electron/js2c/asar_bundle:2:1822)
    at Module._extensions..node (node:internal/modules/cjs/loader:1259:18)
    at Object.func [as .node] (node:electron/js2c/asar_bundle:2:2049)
    at Module.load (node:internal/modules/cjs/loader:1044:32)
    at Module._load (node:internal/modules/cjs/loader:885:12)
    at f._load (node:electron/js2c/asar_bundle:2:13330)
    at o._load (node:electron/js2c/renderer_init:2:3109)
    at Module.require (node:internal/modules/cjs/loader:1068:19)
    at require (node:internal/modules/cjs/helpers:103:18)
    at load (C:\Users\ZI\AppData\Local\Temp\2O4lZlaiKxPE0OCBtsho17I24ti\resources\app.asar\node_modules\node-gyp-build\node-gyp-build.js:22:10)

What should have happened?

Program should list all available ports on machine, but it's crash on importing SerialPort module.

Additional information

No response

Daniel Diesenreither · Answer 1 · Wed Apr 12 2023 05:26:09 GMT+0800 (China Standard Time)

I am facing the same error - is there a solution already?

Noe H · Answer 2 · Sat Apr 29 2023 16:09:50 GMT+0800 (China Standard Time)

Solution is to build in a windows machine. Had the same issue developing in a Mac, the build in a Win VM ran with no issue.

Marlonzao · Answer 3 · Wed Jun 21 2023 05:09:06 GMT+0800 (China Standard Time)

Solution is to build in a windows machine. Had the same issue developing in a Mac, the build in a Win VM ran with no issue.

Not a good solution for automated builds...

Noe H · Answer 4 · Wed Jun 21 2023 05:34:58 GMT+0800 (China Standard Time)

Solution is to build in a windows machine. Had the same issue developing in a Mac, the build in a Win VM ran with no issue.

Not a good solution for automated builds...

We can suppose you got a better/working one, illuminate us!

Marlonzao · Answer 5 · Wed Jun 21 2023 06:27:38 GMT+0800 (China Standard Time)

Solution is to build in a windows machine. Had the same issue developing in a Mac, the build in a Win VM ran with no issue.

Not a good solution for automated builds...

We can suppose you got a better/working one, illuminate us!

Not really, stumbled on this today and also stuck on it, testing everything I can

Gareth Hancock · Answer 6 · Wed Jun 21 2023 23:28:14 GMT+0800 (China Standard Time)

I'm afraid that while the error code is very similar, the closed issue you reference is very unlikely to be related as the root cause of that was broken inbound dependency which was entirely stripped out as part of serialport v10. So I don't think that will allow us to trace the problem.

In trying to replicate your issue I think this comes down to an electron-builder issue which affect cross build for both Mac and Linux targeting windows.

With a very simple project (based on the electron-serialport example) compiling on Linux (ubuntu) and Windows I experience the same problems as described in electron-userland/electron-builder#7574

Even before the application is packaged, the unpackaged output from electron-builder is inconsistent. On Windows it places all of the required data in the app.asar, while on Linux it creates an app.asar.unpacked folder for the serialport package. According to the docs @ https://www.electron.build/generated/platformspecificbuildoptions this seems to be due to it "automatically detecting" that it needs to be unpacked, but as we can see based on the working Windows compile this is not the case, so the detection routing is what seems to be at fault.

I'll continue to dig, but I'm not sure if I will find a fix quickly.

In the meantime I would echo the suggestion to build on a windows instance if you can. Per your comment about concerns with automated builds, one option to enable to build via your Linux machine would be to use Windows in a VM or container.

Marlonzao · Answer 7 · Thu Jun 22 2023 01:02:25 GMT+0800 (China Standard Time)

Thanks for the reply, I too noted this app.asar.unpacked folder, I'll be analyzing it too.

Milos Zivlak · Answer 8 · Fri Jun 23 2023 12:09:40 GMT+0800 (China Standard Time)

Solution is to build in a windows machine. Had the same issue developing in a Mac, the build in a Win VM ran with no issue.

Only reason for using electron to me is option to quickly build project on Linux for windows. If I need windows I would prefer any other native technology.

Gareth Hancock · Answer 9 · Sat Jun 24 2023 01:35:32 GMT+0800 (China Standard Time)

I'll continue to investigate the issue with the cross build via electron-builder, but will keep those investigations in the electron-builder repository to minimise confusion (check out that issue if you want to help with the investigations).

While those investigations progress I might see if the process is any better in electron forge or if it suffers from the same problems

Gareth Hancock · Answer 10 · Mon Jun 26 2023 23:04:32 GMT+0800 (China Standard Time)

Please refer to electron-userland/electron-builder#7574 for potential fix / workaround

If this proves to work for people (and not break anything else) then I'll see about adding it into the documentation website

Gareth Hancock · Answer 11 · Tue Jun 27 2023 05:25:00 GMT+0800 (China Standard Time)

Thanks to the electron-builder team this should now be fixed in their new version 24.5.1

Francis Gulotta · Answer 12 · Tue Jun 27 2023 07:24:30 GMT+0800 (China Standard Time)

@GazHank riveting investigation!

Marlonzao · Answer 13 · Wed Jul 05 2023 04:53:34 GMT+0800 (China Standard Time)

Thanks to the electron-builder team this should now be fixed in their new version 24.5.1

Hello @GazHank sorry to be bothering you again but this error is still happening to me. I've updated my electron-builder to 24.5.2, but my electron is still version 17. I have some screenshots of my ci running the build, but I could't determine why only updating electron-builder didn't fix it.

What test did you ran?

P. J. Reed · Answer 14 · Thu Dec 14 2023 01:50:09 GMT+0800 (China Standard Time)

I know this is an old issue, but I just ran into it and it's still not working for me. I'm using electron 28.0.0, electron-builder 24.9.1, and serialport 12.0.0, so I have up-to-date versions of everything.

When I try to build it in Linux, the build log looks like it should be building @serialport/bindings-cpp for Windows:

  • electron-builder  version=24.9.1 os=6.5.6-76060506-generic
  • loaded configuration  file=/home/preed/src/dashboard/electron-builder.json5
  • writing effective config  file=release/1.0.0/builder-effective-config.yaml
  • rebuilding native dependencies  dependencies=@serialport/bindings-cpp@12.0.1 platform=win32 arch=x64
  • rebuilding native dependency  name=@serialport/bindings-cpp version=12.0.1
  • packaging       platform=win32 arch=x64 electron=28.0.0 appOutDir=release/1.0.0/win-unpacked
  • building        target=portable file=release/1.0.0/dashboard_1.0.0.exe archs=x64
Done in 54.13s.

But the generated binary is in ELF format:

$ file ./release/1.0.0/win-unpacked/resources/app.asar.unpacked/node_modules/@serialport/bindings-cpp/build/Release/bindings.node
./release/1.0.0/win-unpacked/resources/app.asar.unpacked/node_modules/@serialport/bindings-cpp/build/Release/bindings.node: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=67c079f9038b36c6f27cd38ef8f48cccc5f5ca3d, not stripped

Eduardo Torres · Answer 15 · Thu Feb 15 2024 00:48:24 GMT+0800 (China Standard Time)

Hey @pjreed I had the same issue. I set buildDependenciesFromSource to true in the build options and now it works.

P. J. Reed · Answer 16 · Fri Feb 16 2024 01:16:21 GMT+0800 (China Standard Time)

Hey @pjreed I had the same issue. I set buildDependenciesFromSource to true in the build options and now it works.

That doesn't work for me, and I'm not sure how it could possibly work. When setting that, I see this in the output:

  • skipped dependencies rebuild  reason=platform is different and buildDependenciesFromSource is set to true

app-builder-lib appears to be hard-coded to fail if that flag is set but your build platform does not match your build target; see https://github.com/electron-userland/electron-builder/blob/master/packages/app-builder-lib/src/packager.ts#L522. Mine does not since I'm using electron-builder on a Linux machine to build a Windows target.

Eduardo Torres · Answer 17 · Fri Feb 16 2024 01:51:38 GMT+0800 (China Standard Time)

I'm using docker (electronuserland/builder:18-wine-mono) and targeting to windows.

My build command is:

electron-builder --config electron-builder-dev.yml --win --x64

electron-builder-dev.yml

productName: 'My App'
directories:
  output: out


buildDependenciesFromSource: true

win:
  target:
    - nsis
    - zip
  icon: 'resources/my-icon.ico'
  publish:
    provider: 'generic'
    url: 'localhost'

nsis:
  artifactName: '${name}-${version}.${ext}'

Without the buildDependenciesFromSource: true property, I had the same issue mentioned above.

DockerFile

FROM electronuserland/builder:18-wine-mono
ENV WINEARCH=win64
ENV WINEPREFIX=/root/.wine64

COPY . .

npm install && electron-builder --config electron-builder-dev.yml --win --x64

Julian Forrester · Answer 18 · Sat Mar 23 2024 03:11:15 GMT+0800 (China Standard Time)

Hey @pjreed I had the same issue. I set buildDependenciesFromSource to true in the build options and now it works.

That doesn't work for me, and I'm not sure how it could possibly work. When setting that, I see this in the output:
  • skipped dependencies rebuild  reason=platform is different and buildDependenciesFromSource is set to true
app-builder-lib appears to be hard-coded to fail if that flag is set but your build platform does not match your build target; see https://github.com/electron-userland/electron-builder/blob/master/packages/app-builder-lib/src/packager.ts#L522. Mine does not since I'm using electron-builder on a Linux machine to build a Windows target.

Also experiencing this. Did you find a solution?

暴走 · Answer 19 · Mon May 13 2024 14:12:30 GMT+0800 (China Standard Time)

I know this is an old issue, but I just ran into it and it's still not working for me. I'm using electron 28.0.0, electron-builder 24.9.1, and serialport 12.0.0, so I have up-to-date versions of everything.

When I try to build it in Linux, the build log looks like it should be building @serialport/bindings-cpp for Windows:

  • electron-builder  version=24.9.1 os=6.5.6-76060506-generic
  • loaded configuration  file=/home/preed/src/dashboard/electron-builder.json5
  • writing effective config  file=release/1.0.0/builder-effective-config.yaml
  • rebuilding native dependencies  dependencies=@serialport/bindings-cpp@12.0.1 platform=win32 arch=x64
  • rebuilding native dependency  name=@serialport/bindings-cpp version=12.0.1
  • packaging       platform=win32 arch=x64 electron=28.0.0 appOutDir=release/1.0.0/win-unpacked
  • building        target=portable file=release/1.0.0/dashboard_1.0.0.exe archs=x64
Done in 54.13s.

But the generated binary is in ELF format:

$ file ./release/1.0.0/win-unpacked/resources/app.asar.unpacked/node_modules/@serialport/bindings-cpp/build/Release/bindings.node
./release/1.0.0/win-unpacked/resources/app.asar.unpacked/node_modules/@serialport/bindings-cpp/build/Release/bindings.node: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=67c079f9038b36c6f27cd38ef8f48cccc5f5ca3d, not stripped

hi~ Did you find a solution?

P. J. Reed · Answer 20 · Mon May 13 2024 22:42:25 GMT+0800 (China Standard Time)

Unfortunately, just for the record, I have still not found a solution other than "build it in a Windows VM"