What about native dependencies where the .node binary is not the only architecture-specific file?

[Nantris]

Related to lovell/sharp#3622 - Sharp on macOS requires both a .node and and a .dylib binary but @electron/universal only seems to manage the .node files, ignoring the necessity of the .dylib.

I'm not certain this is an @electron/universal issue, but after speaking with Sharp's creator and doing some more thinking, I believe that this is the case. Is that something that can be managed by this project? Or am I misunderstanding the problem?

[Nantris]

Based on this comment, I feel even more confident that this could work if the .dylib files were copied for both architectures, as the .node files already are.

[Nantris]

Anyone have any idea about this?

Sharp is a wildly popular library and I think @electron/universal is a step away from properly supporting it - but I'd love to hear from a contributor or maintainer and find out if I'm misunderstanding. Otherwise maybe we could make a lot more apps universal.

[Nantris]

Friendly bump. This seems to be the only blocker for us to make universal Electron builds.

[Nantris]

@MarshallOfSound do you have any thoughts on this? It seems like an oversight in how universal packages are built that they don't include all of the required native files for both architectures. Instead the bundle only includes a copy for one architecture, so the package just crashes on the other.

[mushan0x0]

I encountered the same problem and tried many solutions but none of them worked.

[MarshallOfSound]

@slapbox We try to automatically merge any file that looks like a AppFileType.MACHO, not sure why it wouldn't be picking up a dylib correctly as it does for instance work for the dylibs embedded in electron.

Do you have a repro case?

[Nantris]

Thanks for your reply @MarshallOfSound. I wonder if it's related to the fact that Sharp (iirc) only downloads the .dylib files for the given platform when it installs itself. I'm not sure exactly how Electron incorporates .dylibs so maybe my question is silly.

I don't have a repro case handy but I'll try to make one in the next week or two.

---

@mushan0x0 thanks for your comment in another thread. If you need this sooner and can create a repro that would be a big help to getting this resolved faster (and to me personally) - all the investigative work on this set me back on some other tasks.

My plan to produce a repro is to modify this boilerplate: https://github.com/electron-react-boilerplate/electron-react-boilerplate/

1. Install Sharp, and upgrade Electron-Builder dep to ^24.0.0
2. Include sharp in the main process
3. Configure the build process to do universal macOS builds here (either inline or via config file)
4. Build on macOS
5. When you run you should produce the error message we've both been encountering (unless I've missed a step)

[Nantris]

@MarshallOfSound one other thing that might be of interest while waiting on the repro - from this comment: electron-userland/electron-builder#7512 (comment)

Is this how you'd expect the file structure to look? It seems unexpected to me that there's no darwin-arm64 or equivalent. Do you mean that the darwin-x64 contents should automatically be made universal by @electron/universal despite the naming convention?

[MarshallOfSound]

@slapbox I had a chance to look into this, it looks like this is super specific to sharp in that the native module build process does not generate that dylib, instead it's generated at install time by the install/libvips script.

Although @electron/rebuild will correctly rebuild the native module it has no idea about the existence of that dylib build process. You'll have to somehow tell electron-builder (no idea how, we don't support that tool) to run the libvips script for each arch during the package phase so that each version of the packaged app has the right dylib.

Closing this out as it's a build script issue not an issue with the universal library

[Nantris]

Thanks so much for your investigation @MarshallOfSound, it's greatly appreciated.