Detected file that's the same in both x64 and arm64 builds

[Tapestes]

Running universal via electron-forge package --arch=universal results in the following error message:

An unhandled rejection has occurred inside Forge:
Error: Detected file "Contents/Resources/app/node_modules/lzma-native/prebuilds/darwin-arm64/electron.napi.node" that's the same in both x64 and arm64 builds and not covered by the x64ArchFiles rule: "undefined"

Any thoughts on how to handle this? Appreciate the help.

[tthef]

I have the same problem with 7zip-bin, which is pulled in by electron-updater. The simple fix in @electron/universal would be to detect if the two files are identical (e.g., sha check) prior to calling lipo, and if they are, just copy the first file. I don't think there is any work around for this just now. (Updated: the copy in fact happens, all that's require is to catch the lipo error, check error.stderr for 'have the same architecture', rethrow if not present).

[navdeepm20]

Any resolution for this issue? I am using electron forge.

[vadimdemedes]

Same issue appears to happen when building a universal app that uses fsevents native module.

Detected file "Contents/Resources/app/node_modules/fsevents/fsevents.node" that's the same in both x64 and arm64 builds and not covered by the x64ArchFiles rule: "undefined"

[rstupek]

I'm also getting the fsevents file detected as duplicate when including chokidar. Any direction on how to resolve this?

[MarshallOfSound]

@navdeepm20 I hid your comment as it is incorrect and will result in folks having broken apps.

The issue here folks is that you are packaged a "universal" app but the fsevents.node native module is only being built for one architecture. This warning means that you aren't rebuilding native modules for the correct architecture.

In some cases (like in the original issue's case) this is expected behavior and requires you to allowlist the file as the path Contents/Resources/app/node_modules/lzma-native/prebuilds/darwin-arm64/electron.napi.node is clearly architecture specific and is supposed to be the same in both files, I would assume there is an equivalent darwin-x64 path as well.

In the fsevents case it's simply that the module isn't being rebuilt for some reason, you may need to appropriately integrate @electron/rebuild into your build process or use a tool like Electron Forge which does this for you

[vadimdemedes]

I think moving chokidar/fsevents (depending what you use) to dependencies from devDependencies solved it for me and made @electron/rebuild rebuild it correctly for every arch.

[javierguzman]

@navdeepm20 I hid your comment as it is incorrect and will result in folks having broken apps.

The issue here folks is that you are packaged a "universal" app but the fsevents.node native module is only being built for one architecture. This warning means that you aren't rebuilding native modules for the correct architecture.

In some cases (like in the original issue's case) this is expected behavior and requires you to allowlist the file as the path Contents/Resources/app/node_modules/lzma-native/prebuilds/darwin-arm64/electron.napi.node is clearly architecture specific and is supposed to be the same in both files, I would assume there is an equivalent darwin-x64 path as well.

In the fsevents case it's simply that the module isn't being rebuilt for some reason, you may need to appropriately integrate @electron/rebuild into your build process or use a tool like Electron Forge which does this for you

Hello @MarshallOfSound how do we tell to build for each architecture? I created yesterday the issue #76 and I believe it is more or less the same problem. In my case drivelist seems to be built for x86 and I have arm64. So how should I tell electron/universal to build for x86 and arm64? Thank you in advance and regards

[tthef]

The issue here folks is that you are packaged a "universal" app but the fsevents.node native module is only being built for one architecture. This warning means that you aren't rebuilding native modules for the correct architecture.

@MarshallOfSound I don't think that's what the problem is; fsevents.node is a universal binary so it's same for both x86 and arm64. lipo -create can't be called on universal binaries (no point), and if you do, it errors with 'the same architectures' error. It unhelfully only reports the first architecture in the universal binary, so it's not immediately obvious it is actually two identical universal binaries you are trying to combine. The fix for this would be to check if the file is a univeral binary (lipo -archs) before trying to combine it.