Skip to content
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

Closed
ghost opened this issue Jan 18, 2021 · 17 comments
Closed

Can't use extraFiles that contain Universal binaries #5552

ghost opened this issue Jan 18, 2021 · 17 comments

Comments

@ghost
Copy link

ghost commented Jan 18, 2021

  • Version: 22.10.4
  • Electron Version: 11.2.0
  • Electron Type (current, beta, nightly): current
  • Target: macOS Universal

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:

"extraFiles": [
  {
    "from": "binaries/${arch}",
    "to": "binaries"
  }
],

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.

@XRenSiu
Copy link

XRenSiu commented Feb 8, 2021

I have x64 and arm64 binary built from another project, x64 need support macOS 10.13 and it includes Frameworks/libswift* , but arm64 doesn't include Frameworks

use @electron/universal, i get some error While trying to merge mach-o files across your apps we found a mismatch, the number of mach-o files is not the same between the arm64 and x64 builds

As @IanMDay said:

or have a new configuration option for a 'universal' arch to indicate the files are already universal

that is great.

@Hinton
Copy link
Contributor

Hinton commented Mar 20, 2021

I just encountered the same issue as @XRenSiu, we bundle a Safari extension inside the extraFiles which contains Frameworks/libswift* which are no longer used in arm64. Adding an option to inject extraFiles for universal should solve it for us.

Although we still build separate x64 and arm64 packages for dmg (to lower space usage), where we would want to always include the universal binaries as well.

@XRenSiu
Copy link

XRenSiu commented Mar 24, 2021

Workaround

  1. prepare universal extralFiles

  2. use afterSign hook

    • copy extraFiles into packaged app
    • resign code
module.exports = async function(packContext){
  const {
    appOutDir,
    packager
  } = packContext

  const appFile = path.join(
    appOutDir,
    `${packager.appInfo.productFilename}.app`
  )
  copy('<extraFile path>',path.join(appFile, 'Contents/Library/xxxxx/xxx.qlgenerator'))

  // resign
  await packager.signApp(packContext, true)
}

milot-mirdita added a commit to soedinglab/MMseqs2-App that referenced this issue Apr 15, 2021
milot-mirdita added a commit to soedinglab/MMseqs2-App that referenced this issue Apr 15, 2021
@stale
Copy link

stale bot commented Jun 2, 2021

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.

@stale stale bot added the backlog label Jun 2, 2021
@ghost
Copy link
Author

ghost commented Jun 3, 2021

Yes, its still relevant.

@stale stale bot removed the backlog label Jun 3, 2021
@alectrocute
Copy link

+1. Currently stuck here.

@mmaietta
Copy link
Collaborator

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
#5552 (comment)

@alectrocute
Copy link

alectrocute commented Jul 28, 2021

@mmaietta Thanks so much for your help. How are you "preparing your extraFiles for universal"? I have a .node native module that I require("./src/release/Build/my_module.node"). Am I supposed to use electron-rebuild to compile it for universal? Any ideas?

When I build for universal, electron-builder and/or @electron/universal only include the x64 binary. I am not yet using extraFiles.

@stale
Copy link

stale bot commented Oct 2, 2021

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.

@stale stale bot added the backlog label Oct 2, 2021
@Hinton
Copy link
Contributor

Hinton commented Oct 4, 2021

It's still relevant. The only current work-around requires signing twice.

@stale stale bot removed the backlog label Oct 4, 2021
@alectrocute
Copy link

alectrocute commented Oct 4, 2021

Thanks for keeping this ticket open @Hinton! As a side effect of this bug, I've become pretty proficient using lipo manually.

@pmstani
Copy link

pmstani commented Mar 17, 2022

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:

fatal error: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/lipo: /private/var/folders/8p/ylf73sqs61bgxnj99fngjlq00000gn/T/electron-universal-dqUU4L/Tmp.app/Contents/Resources/assets/plugins/xxxxxxxx.dylib and /Users/xxxxxxx/Documents/xxxxxxx/xxxxxxx/release/mac-universal--arm64/xxxxxxxx.app/Contents/Resources/assets/plugins/xxxxxxx.dylib have the same architectures (x86_64) and can't be in the same fat output file

Has anybody found a way to include an already compiled-for-universal dynamic lib without encountering this error?

@ghost
Copy link
Author

ghost commented Mar 17, 2022

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.

@pmstani
Copy link

pmstani commented Mar 17, 2022

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!

@ghost
Copy link
Author

ghost commented Mar 18, 2022

My prebuilt universals get lipo extracted before the build into binaries/arm64 and binaries/x64

lipo -extract arm64 myUniversalBinary -output binaries/arm64/myUniversalBinary
lipo -extract x86_64 myUniversalBinary -output binaries/x64/myUniversalBinary

Then included into the package with extraFiles:

"extraFiles": [
    {
        "from": "binaries/${arch}",
        "to": "binaries"
    }
],

The builder then uses lipo to recombine them back again.

@pmstani
Copy link

pmstani commented Mar 18, 2022

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!

@jtbandes
Copy link
Contributor

Seems like this is fixed by electron/universal#47 + #6913, if you put the file in the new x64ArchFiles allowlist.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants