Closed Nantris closed 1 year ago
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.
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.
Friendly bump. This seems to be the only blocker for us to make universal Electron builds.
@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.
I encountered the same problem and tried many solutions but none of them worked.
@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?
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 .dylib
s 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/
^24.0.0
@MarshallOfSound one other thing that might be of interest while waiting on the repro - from this comment: https://github.com/electron-userland/electron-builder/issues/7512#issuecomment-1500613835
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?
@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
Thanks so much for your investigation @MarshallOfSound, it's greatly appreciated.
Related to https://github.com/lovell/sharp/issues/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?