Problems building for Windows via Docker images on an M1/M2 (Apple Silicon)

[Nantris]

I'm considering purchasing some new hardware for our automated processes but I would hate to find out that we can't build for Windows/Linux from newer Mac machines only after purchasing the hardware.

Can anyone advise, either based on experience or even speculatively? I understand there can be compatibility problems with Docker images and I don't want to get into a situation where we have to build and maintainer our own images.

[mmaietta]

I haven't had any issues with it. I have an M2 mac and unit tests run successfully using the electron-builder wine image. I also have compiled windows and linux distributions (a long while ago at least) on mac.

Docker will complain the image is for a different architecture, but I've never had issues with the bundling process and running the app.

[Nantris]

Awesome! Thanks so much for taking the time to reply @mmaietta - I really appreciate you!

[mmaietta]

@Slapbox I just checked again and I do have issues bundling windows nsis on mac m2 now that I'm home again

⨯ cannot execute  cause=signal: segmentation fault
                    errorOut=qemu: uncaught target signal 11 (Segmentation fault) - core dumped

                    command=wine /root/.cache/electron-builder/winCodeSign/winCodeSign-2.6.0/rcedit-ia32.exe '/tmp/et-db411cd21f3bbd882f3a5a30c58db6ff/t-8WkR4h/test-project-8/dist/win-unpacked/Test App ßW.exe' --set-version-string FileDescription 'Test App ßW' --set-version-string ProductName 'Test App ßW' --set-version-string LegalCopyright 'Copyright © 2024 Foo Bar' --set-file-version 1.1.0.42 --set-product-version 1.1.0.42 --set-version-string InternalName 'Test App ßW' --set-version-string OriginalFilename '' --set-version-string CompanyName 'Foo Bar' --set-icon /tmp/et-db411cd21f3bbd882f3a5a30c58db6ff/t-8WkR4h/test-project-8/build/icon.ico

Basically, app-builder project needs to compile/provide a rcedit.exe that is x64 compatible since arm64 can run rosetta for it, but is unable to execute an ia32 binary.

As such, you'll still need a linux or windows device until the upstream project is revisited

[mmaietta]

Looks like there's already an issue you can track (and bump up) https://github.com/develar/app-builder/issues/56

[Nantris]

Thanks so much again for taking a look into this @mmaietta! You got that message in right after I filed a duplicate 😂

PS: Hopefully I got your explanation right in my comment on https://github.com/develar/app-builder/issues/56

[Nantris]

@mmaietta I noticed that there's this file available in an Electron repo. I don't know that it does any good for moving this forward, but in case it might: https://github.com/electron/rcedit/releases (I may have already brought this up but I couldn't find that comment.)

I saw that app-builder does at least reference rcedit-x64.exe, but unfortunately this is all above my pay grade and I assume that still depends on the executable being available in some directory included in the PATH?

I wonder if anything already available might be able to move this forward with @develar MIA. I noticed his Github activity has been empty for a few weeks now, which, while still short, is the longest stretch of inactivity for him in over a decade - and I haven't seen him comment on anything in all of 2024.

[mmaietta]

So the only way to add that release, which I'm wholly open to doing so, is to get it added to https://github.com/electron-userland/electron-builder-binaries

I've emailed develar previously asking for the release process of that repo (and to get write access to it) and heard back from him, but haven't received the access nor instructions on how each release is handled yet.

If I can get write access, I may change up the repo release process to be automated, as right now it's all manual in tagging each release with a sha hash for a specific subset of files in the repo.

[Nantris]

Hmm... I'm not sure how (or if one can) list out users with commit privileges for a repo, but I noted that most of the Electron team are listed as members. I wonder if they might have commit permissions. All the PRs I looked at were indeed merged by develar though.

But I did just notice there's a very old version of rcedit-x64.exe available in the repo already. I wonder if that does any good? It's five years old, but it is x64. https://github.com/electron-userland/electron-builder-binaries/tree/master/winCodeSign

Although it's outside my wheelhouse, based on the minimal changes listed, it seems promising: https://github.com/electron/rcedit/compare/v1.1.1...v2.0.0

[mmaietta]

Update: So I was able to modify app-builder to leverage the x64 version of recedit, and it appears that it may not be the underlying issue here. I'm wondering if the wine x64 executable is not runnable for x64 docker images on arm64 macs and if I'm barking up the wrong tree. Unfortunately, I'm falling even further out of my element here as I'm not familiar with qemu, segfaults, or how to debug this further. Any help would be greatly appreciated!

  ⨯ cannot execute  cause=signal: segmentation fault
                    errorOut=qemu: uncaught target signal 11 (Segmentation fault) - core dumped

                    command=wine /root/.cache/electron-builder/winCodeSign/winCodeSign-2.6.0/rcedit-x64.exe '/tmp/et-db411cd21f3bbd882f3a5a30c58db6ff/t-TZEDPi/test-project-0/dist/win-unpacked/Test App ßW.exe' --set-version-string FileDescription 'Test Application (test quite “ #378)' --set-version-string ProductName 'Test App ßW' --set-version-string LegalCopyright 'Copyright © 2024 Foo Bar' --set-file-version 1.1.0.42 --set-product-version 1.1.0.42 --set-version-string InternalName 'Test App ßW' --set-version-string OriginalFilename '' --set-version-string CompanyName 'Foo Bar' --set-icon /tmp/et-db411cd21f3bbd882f3a5a30c58db6ff/t-TZEDPi/test-project-0/build/icon.ico     

If you'd like to try messing around with testing approaches yourselves, this is the repo (that significantly needs developer-setup instructions still). https://github.com/develar/app-builder

go install -a -v github.com/go-bindata/go-bindata/...@latest
make build-all

To use in electron-builder, I updated the package.json command to include CUSTOM_APP_BUILDER_PATH and then mount the locally-compiled app-builder binary

"test-linux": "docker run --rm --env CUSTOM_APP_BUILDER_PATH=/usr/bin/app-builder -v /Users/mmaietta/Development/app-builder/linux/x64/app-builder:/usr/bin/app-builder -e DEBUG=${DEBUG:-} -e UPDATE_SNAPSHOT=${UPDATE_SNAPSHOT:-false} -e TEST_FILES=\"${TEST_FILES:-HoistedNodeModuleTest}\" -v $(pwd):/project -v $(pwd)-node-modules:/project/node_modules -v $HOME/Library/Caches/electron:/root/.cache/electron -v $HOME/Library/Caches/electron-builder:/root/.cache/electron-builder electronuserland/builder:18-wine-mono /bin/bash -c \"pnpm install && node ./test/out/helpers/runTests.js\"",

I'm testing with TEST_FILES=winPackagerTest pnpm run test-linux and modified the winPackagerTest->test.only("win zip", ....) test set to .only to speed up testing iterations

[Nantris]

Thank you as always for your great work @mmaietta!

This is a bit outside my wheelhouse as well. I wonder what version of Wine being used is? Is it possible there's any newer version?

ChatGPT had these recommendations (probably fruitless):

• Install potential dependencies: winetricks vcrun2015
• Run the command with more debugging output: WINEDEBUG=+all wine rcedit-x64.exe

I did come across this issue, which is discouraging: https://github.com/nativefier/nativefier/issues/375

You're testing with the older version of rcedit-x64.exe, right? It doesn't seem like the newer version makes any changes that would make a difference, but maybe I'm wrong: https://github.com/electron/rcedit/releases

[mmaietta]

I think I was barking up the wrong tree. I checked the arch of the wine binary and it is indeed 32-bit (01 instead of 02)

root@e0ac54a98d9e:/project# wine --version
wine-6.0.4
root@e0ac54a98d9e:/project# od -An -t x1 -j 4 -N 1 /usr/bin/wine
 01
root@e0ac54a98d9e:/project# od -An -t x1 -j 4 -N 1 /usr/bin/wine64
 02

(I also tried with latest wine 9.0.0)

Forcing app-builder to use wine64 returns the following error:

  ⨯ cannot execute  cause=exit status 1
                    errorOut=wine: '/root/.wine' is a 32-bit installation, it cannot support 64-bit applications.

Which is coming from this snapshot home dir https://github.com/electron-userland/electron-builder/blob/81da7c1491e2b3ff2f7b476f8128183f57074ff5/docker/wine/Dockerfile#L18

But I also found these: https://github.com/electron-userland/electron-builder-binaries/releases?q=wine&expanded=true

The investigation continues...

[mmaietta]

@Nantris I noticed there's special logic in app-builder that processes wine64 correctly on macOS devices, separate from the logic used within the docker container. What happens if you build with electron-builder for win/linux without using the docker container? (I recognize that's non-ideal due to the non-ephemeral nature of not using a docker container, but wanted to see if a backup/alternative route is possible to unblock you)

[Nantris]

Thanks again for your work on this @mmaietta!

I'm not sure I follow. Do you mean build the app for win/linux natively, directly on the macOS device? Unfortunately that wouldn't be an option for us due to not being able to compile our node dependencies. But if there's some way that testing our build (sans node dependencies) could help out, just let me know and I'll be happy to give it a try!

I wonder why no new releases on the page you linked for 5 years now? Maybe it's no longer thought to be needed? https://github.com/electron-userland/electron-builder-binaries/releases?q=wine&expanded=true

[mmaietta]

So I tried just installing wine 9.0 via brew and tested it with a temporary .wine home folder to recreate the wine config from scratch. This was purely to test whether wine could even work on an arm64 mac, without docker. Unfortunately, I'm hitting another error/blocker that I'm struggling to understand.

This also uses the most recent version of rcedit-x64.exe from https://github.com/electron/rcedit/releases

WINEPREFIX=~/wine-test wine64 ~/Development/rcedit-x64.exe ./dist/win-unpacked/Product.exe  --set-version-string FileDescription Product --set-version-string ProductName Product --set-version-string LegalCopyright 'Copyright © 2024 Company' --set-file-version 1.0.0 --set-product-version 1.0.0.0 --set-version-string InternalName Product --set-version-string OriginalFilename '' --set-version-string CompanyName Company 

0024:fixme:kernelbase:AppPolicyGetProcessTerminationMethod FFFFFFFFFFFFFFFA, 000000000011FE80

I haven't been able to identify any documentation on AppPolicyGetProcessTerminationMethod or how to resolve it unfortunately. My google searches aren't returning anything for it and ChatGPT wasn't too helpful either. FWIW, I don't have an adequate way to test whether it even worked AFAICT and if the error message is just a false positive, but the fact we're receiving something labeled fixme in the error message seems concerning in the sense that I'm wondering if rcedit is even designed to work on arm64 macs or used within wine (or maybe just the combo of both conditions). (I also tried by forcing rosetta 2 emulation using arch -x86_64 and still had an error result)

Also received this just trying to init the wine home dir. But it's worth noting that I was still able to launch Internet Explorer from the initialized wine home dir regardless.

wine64 '~/.wine/drive_c/Program Files (x86)/Internet Explorer/iexplore.exe'

I'll keep hammering away at this, but overall, I'm really confused.

[github-actions[bot]]

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 30 days.

[Nantris]

Not stale.

I guess this notification fell through the cracks.

@mmaietta thank you for your efforts on this, and no pressure to get it working! I don't know if you have ChatGPT plus, nor would I presume you want to use your limited o1-preview limit on this topic, nor do I even know it would help - but that might be a new avenue to pursue for answers.

I've only used it very slightly and I'm not terribly hopeful it would offer correct answers, but perhaps new insights would emerge at least.

---

FWIW, I don't have an adequate way to test whether it even worked AFAICT

Can you clarify this bit? What would be a valid test or required to do one?

---

I'm sorry I can't be more help on this; so much of it is above my paygrade.