Building using unsupported rust gnu toolchain for windows

[39george]

Hello everyone. I’m creating an app with tauri. I build it with [cargo cross(https://github.com/cross-rs/cross) with rust GNU toolchain for windows. I build it on linux with windows as a target platform. In official docs there’s a recommendation to use MSVC, but the gmp-mpfr-sys dep I use in my rust project does not support MSVC, so I’m forced to use GNU.
I compile project in 2 steps:

cross build --target x86_64-pc-windows-gnu --package signer --release
# then
cargo tauri bundle --target x86_64-pc-windows-gnu

It produces these logs

󰂄 3% ❯ cargo tauri bundle --target x86_64-pc-windows-gnu -d
        Warn Cross-platform compilation is experimental and does not support all features. Please use a matching host system for full compatibility.
        Warn Signing, by default, is only supported on Windows hosts, but you can specify a custom signing command in `bundler > windows > sign_command`, for now, skipping signing the installer...
        Info Patching binary "/home/george/dev/work/business_boom/rust-custody-wallet/target/x86_64-pc-windows-gnu/debug/signer.exe" for type msi
        Warn ignoring msi
        Info Patching binary "/home/george/dev/work/business_boom/rust-custody-wallet/target/x86_64-pc-windows-gnu/debug/signer.exe" for type nsis
        Info Target: x64
     Running makensis to produce /home/george/dev/work/business_boom/rust-custody-wallet/target/x86_64-pc-windows-gnu/debug/bundle/nsis/signer_0.1.0_x64-setup.exe
warning 5202: -OUTPUTCHARSET is disabled for non Win32 platforms.
        Warn Signing, by default, is only supported on Windows hosts, but you can specify a custom signing command in `bundler > windows > sign_command`, for now, skipping signing the installer...
    Finished 1 bundle at:
        /home/george/dev/work/business_boom/rust-custody-wallet/target/x86_64-pc-windows-gnu/debug/bundle/nsis/signer_0.1.0_x64-setup.exe

The installer is created, so I sent it to the users with windows machines. But, when users on windows run the app, they see an error from the screenshot that I attached:

Can you please help me, why, despite successful build, the app doesn’t work on windows

Here’s the tauri.conf

{
  "$schema": "https://schema.tauri.app/config/2",
  "productName": "signer",
  "version": "0.1.0",
  "identifier": "com.signer.corp",
  "build": {
    "beforeDevCommand": "npm run dev",
    "devUrl": "http://localhost:1420",
    "beforeBuildCommand": "npm run build",
    "frontendDist": "../dist"
  },
  "app": {
    "windows": [
      {
        "title": "signer",
        "width": 1280,
        "height": 720,
        "dragDropEnabled": false
      }
    ],
    "security": {
      "csp": null
    },
    "withGlobalTauri": true
  },
  "bundle": {
    "active": true,
    "targets": "all",
    "icon": [
      "icons/32x32.png",
      "icons/128x128.png",
      "icons/[email protected]",
      "icons/icon.icns",
      "icons/icon.ico"
    ]
  }
}

Here’s the vite.conf

import { defineConfig } from 'vite';
import react from '@vitejs/plugin-react';
import path from 'path';
import fs from 'fs';

// @ts-expect-error process is a nodejs global
const host = process.env.TAURI_DEV_HOST;

// https://vitejs.dev/config/
export default defineConfig(async () => ({
    plugins: [
        react(),
        {
            name: 'raw-svg-loader',
            transform(_, id) {
                if (id.endsWith('.svg')) {
                    // For regular SVG imports, return the raw SVG content
                    if (!id.includes('?')) {
                        // Read the file and return raw SVG content
                        const filePath = id.split('?')[0]; // Remove query params
                        const svgContent = fs.readFileSync(filePath, 'utf8');
                        return `export default ${JSON.stringify(svgContent)}`;
                    }
                }
            },
        },

    ],
    resolve: {
        alias: {
            '@': path.resolve(__dirname, './src'),
        },
    },
    // Vite options tailored for Tauri development and only applied in `tauri dev` or `tauri build`
    //
    // 1. prevent vite from obscuring rust errors
    clearScreen: false,
    // 2. tauri expects a fixed port, fail if that port is not available
    server: {
        port: 1420,
        strictPort: true,
        host: host || false,
        hmr: host
            ? {
                protocol: "ws",
                host,
                port: 1421,
            }
            : undefined,
        watch: {
            // 3. tell vite to ignore watching `src-tauri`
            ignored: ["**/src-tauri/**"],
        },
    },
}));

Maybe some url is set incorrectly? Why it can't reach localhost?

[FabianLars]

2 things i noticed:

1. if you do not run tauri build then your beforeBuildCommand will not be executed which means that you're potentially missing the ../dist dir (contents
2. the command you used in the logs is a different one than in your code snipped. You're saying you used cargo tauri bundle --target x86_64-pc-windows-gnu but in the logs you used cargo tauri bundle --target x86_64-pc-windows-gnu -d which would tell tauri to use the binary from the target/debug build which often is the dev build -> since you're cross-compiling i doubt this is the issue but still wanted to mention it.

[39george]

Thanks! You were spot-on on both points.

1) beforeBuildCommand
My broken flow was:

cross build --target x86_64-pc-windows-gnu --release
cargo tauri bundle --target x86_64-pc-windows-gnu

That second step didn’t recompile the Rust binary, so beforeBuildCommand wasn’t run for the exe that got bundled ⇒ ../dist wasn’t embedded.

What fixed it was doing it in one step so Tauri runs the front build and rebuilds the Rust exe:

cargo tauri build --runner cross --target x86_64-pc-windows-gnu

After that the exe grew ~100 KB so the UI is actually embedded.

2) -d flag
You’re right — that -d line was from a debug trial. The failing installer came from the two-step flow above, but point taken: -d would use the debug binary and can bite.
Thanks again for the pointers!