-
-
Notifications
You must be signed in to change notification settings - Fork 1.7k
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
Can't use extraFiles that contain Universal binaries #5552
Comments
I have x64 and arm64 binary built from another project, x64 need support macOS 10.13 and it includes use As @IanMDay said:
that is great. |
I just encountered the same issue as @XRenSiu, we bundle a Safari extension inside the Although we still build separate |
Workaround
|
Doesn't work yet because of electron-userland/electron-builder#5552
Doesn't work yet because of electron-userland/electron-builder#5552
Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward? This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. |
Yes, its still relevant. |
+1. Currently stuck here. |
Pretty sure any changes that could be made here for detecting whether a binary is already universal would be part of either @electron/electron-osx-sign or @electron/universal libraries. I'd advocate for using this workaround |
@mmaietta Thanks so much for your help. How are you "preparing your When I build for universal, |
Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward? This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. |
It's still relevant. The only current work-around requires signing twice. |
Thanks for keeping this ticket open @Hinton! As a side effect of this bug, I've become pretty proficient using |
Hello everyone, I have a related issue (I think) with a .dylib which we build directly from Xcode as universal and try to include in our asset folder. However, when packaging our Electron app for universal, it builds properly for x64, arm64 and then when it actually starts the universal part, we get the following error:
Has anybody found a way to include an already compiled-for-universal dynamic lib without encountering this error? |
I ended up using lipo -extract to split the universal out to its distinct parts and place those files into the x64 and arm folders. |
So basically you didn’t add the binaries in the extraResources field of package.json, packaged as usual, then used lipo -extract, then placed the files manually? And then I guess you need to recombine the thing? Sorry if my question seems dumb, trying to understand how lipo works :/ Thanks! |
My prebuilt universals get lipo extracted before the build into binaries/arm64 and binaries/x64
Then included into the package with extraFiles: "extraFiles": [
{
"from": "binaries/${arch}",
"to": "binaries"
}
], The builder then uses lipo to recombine them back again. |
Thanks that was very useful. I figured it out at the same time I received your reply, but I'm sure it'll be useful to many others! |
Seems like this is fixed by electron/universal#47 + #6913, if you put the file in the new |
I have universal binaries built from another project which I want to include via extraFiles, and have been doing so a while, but I've since updated builds to create Universal binaries.
I'm specifying the folder for the binaries as:
So the configuration only expects to find files in x64 and arm64 folders, so it only attributes these files to one of those architectures.
Ideally, it should either test the contents of the files given in either folder, or have a new configuration option for a 'universal' arch to indicate the files are already universal, or additionally search the universal arch as well as x64 and arm64.
I've resorted to splitting the binaries with
lipo -extract
for now so that builder is happy, but I don't think this is an ideal solution.The text was updated successfully, but these errors were encountered: