Cross-compilation with Wails | Chris' Blog<br>On 2025-12-9, I tested the cross-compilation of the official Svelte template of Wails v2.11.0, a desktop app framework for Go, on my amd64 laptop running Ubuntu 24 with Go v1.25.5. Of course, the results may change in the future as Wails and Go are being improved. Go is known for making cross-compilation much easier than most other languages, and that is mostly still true when using frameworks like Wails. Creating executable files and/or installers for each of several platforms is sometimes as simple as listing those platforms in a command:<br>wails build -clean -nsis \<br>-platform 'linux/amd64,windows/amd64,windows/arm64,windows/386'<br>The above command creates these files:<br>build<br>└── bin<br>├── my-app-386.exe<br>├── my-app-amd64.exe<br>├── my-app-amd64-installer.exe<br>├── my-app-arm64.exe<br>├── my-app-arm64-installer.exe<br>└── my-app-linux-amd64<br>With that, we already have executables and installers for Linux and Windows! I didn’t include MacOS in the list of platforms because Apple generally does not allow cross-compilation. I don’t think there’s anything Wails or Go can do about that. (When I include darwin in the list, the platform is skipped with the message WARNING Crosscompiling to Mac not currently supported.)<br>When I accidentally included a platform that doesn’t exist, I got a helpful message that included this:<br>Supported platforms: darwin,darwin/amd64,darwin/arm64,darwin/universal,linux,linux/amd64,linux/arm64,linux/arm,windows,windows/amd64,windows/arm64,windows/386<br>Are they statically linked?#<br>According to Linux’s ldd command (which prints shared object dependencies), the Windows executables and installers are statically linked and the Linux one is dynamically linked:<br>$ ldd build/bin/*<br>build/bin/my-app-386.exe:<br>not a dynamic executable<br>build/bin/my-app-amd64.exe:<br>not a dynamic executable<br>build/bin/my-app-amd64-installer.exe:<br>not a dynamic executable<br>build/bin/my-app-arm64.exe:<br>not a dynamic executable<br>build/bin/my-app-arm64-installer.exe:<br>not a dynamic executable<br>build/bin/my-app-linux-amd64:<br>linux-vdso.so.1 (0x00007ffdbe4c7000)<br>libglib-2.0.so.0 => /lib/x86_64-linux-gnu/libglib-2.0.so.0 (0x000079e7a3ff0000)<br>libwebkit2gtk-4.0.so.37 => /lib/x86_64-linux-gnu/libwebkit2gtk-4.0.so.37 (0x000079e7a0400000)<br>libgtk-3.so.0 => /lib/x86_64-linux-gnu/libgtk-3.so.0 (0x000079e79fc00000)<br>...<br>The file command confirms this:<br>$ file build/bin/*<br>build/bin/my-app-386.exe: PE32 executable (GUI) Intel 80386, for MS Windows, 7 sections<br>build/bin/my-app-amd64.exe: PE32+ executable (GUI) x86-64, for MS Windows, 9 sections<br>build/bin/my-app-amd64-installer.exe: PE32 executable (GUI) Intel 80386 (stripped to external PDB), for MS Windows, Nullsoft Installer self-extracting archive, 7 sections<br>build/bin/my-app-arm64.exe: PE32+ executable (GUI) Aarch64, for MS Windows, 7 sections<br>build/bin/my-app-arm64-installer.exe: PE32 executable (GUI) Intel 80386 (stripped to external PDB), for MS Windows, Nullsoft Installer self-extracting archive, 7 sections<br>build/bin/my-app-linux-amd64: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=8ce9189206c3fc10a0fdfb874b0a5cd7b5f61ec7, for GNU/Linux 3.2.0, stripped<br>I tried to force static linking for the Linux executable by using -ldflags '-extldflags "-static"', but I got many errors including:<br>/usr/bin/ld: /tmp/go-link-3304063632/000004.o: in function `_cgo_77133bf98b3a_C2func_getaddrinfo':<br>/tmp/go-build/cgo_unix_cgo.cgo2.c:60:(.text+0x37): warning: Using 'getaddrinfo' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking<br>There may still be a way to force static linking for the Linux executable, but I’m not aware of it yet.<br>What about linux/arm64?#<br>Unfortunately, cross-compiling from linux/amd64 to linux/arm64 doesn’t work right now (see output below). I searched Wails’ repo and found others have the same problem. There doesn’t seem to be a workaround. Here’s the output:<br>$ wails build -platform 'linux/arm64'<br>Wails CLI v2.11.0
# Build Options
Platform(s) | linux/arm64<br>Compiler | /usr/local/go/bin/go<br>Skip Bindings | false<br>Build Mode | production<br>Devtools | false<br>Frontend Directory | /home/chris/repos/my-app/frontend<br>Obfuscated | false<br>Skip Frontend | false<br>Compress | false<br>Package | true<br>Clean Bin Dir | false<br>LDFlags |<br>Tags | []<br>Race Detector | false
# Building target: linux/arm64
• Generating bindings: Done.<br>• Installing frontend dependencies: Done.<br>• Compiling frontend: Done.<br>• Compiling application: # runtime/cgo<br>gcc_arm64.S: Assembler messages:<br>gcc_arm64.S:30: Error: no such instruction: `stp x29,x30,[sp,'<br>gcc_arm64.S:34: Error: operand size mismatch for `mov'<br>gcc_arm64.S:36: Error: no such instruction: `stp x19,x20,[sp,'<br>gcc_arm64.S:39: Error: no such instruction: `stp x21,x22,[sp,'<br>gcc_arm64.S:42: Error: no such instruction: `stp x23,x24,[sp,'<br>gcc_arm64.S:45: Error: no...