[bug] failed to cross compile icons/icon.ico into a Windows Resource tauri-build 2.0.0-alpha.4

[Guiguiprim]

Describe the bug

Basic example fails to cross compile for windows msvc with tauri = "2.0.0-alpha.8" and tauri-build = "2.0.0-aplha.4"

Caused by:
  process didn't exit successfully: `/project/target/release/build/app-a62c9b0b39a2abda/build-script-build` (exit status: 1)
  --- stdout
  cargo:rerun-if-env-changed=TAURI_CONFIG
  cargo:rerun-if-changed=tauri.conf.json
  cargo:rustc-cfg=desktop
  cargo:rustc-env=TAURI_ANDROID_PACKAGE_PREFIX=fr_my_app
  cargo:rustc-env=TAURI_TARGET_TRIPLE=x86_64-pc-windows-msvc
  package.metadata does not exist
  failed to compile `icons/icon.ico` into a Windows Resource file during tauri-build: No such file or directory (os error 2)

It does work with tauri = "1.2" and tauri-build = "1.2"

In the error /project/target/release/build/app-a62c9b0b39a2abda/build-script-build would be expected to be /project/target/x86_64-pc-windows-msvc/release/build/app-a62c9b0b39a2abda/build-script-build.
Looks like if the target is not correctly propagated somewhere.

Reproduction

No response

Expected behavior

No response

Platform and versions

platform: windows (cross compiled in a nix environment)

Stack trace

No response

Additional context

No response

[karandit]

I can confirm this error.

   Compiling reproduce-bug v0.0.0 (/usr/src/examples/reproduce-bug/src-tauri)
error: failed to run custom build command for `reproduce-bug v0.0.0 (/usr/src/examples/reproduce-bug/src-tauri)`

Caused by:
  process didn't exit successfully: `/usr/src/examples/reproduce-bug/src-tauri/target/release/build/reproduce-bug-97c168d7b9b39afd/build-script-build` (exit status: 1)
  --- stdout
  cargo:rerun-if-env-changed=TAURI_CONFIG
  cargo:rerun-if-changed=tauri.conf.json
  cargo:rustc-cfg=desktop
  cargo:rustc-env=TAURI_ANDROID_PACKAGE_PREFIX=io_serokell
  cargo:rustc-env=TAURI_TARGET_TRIPLE=x86_64-pc-windows-msvc
  failed to compile `icons/icon.ico` into a Windows Resource file during tauri-build: No such file or directory (os error 2)
       Error failed to build app: failed to build app

[Guiguiprim]

The same issue can be reproduced with the upcoming tauri-build = "1.3" (branch release/version-updates, commit 231c170276c2122cda30245cb012a7e6b1789ccd)

[karandit]

After some investigation, I guess this issue is related to this code

Honestly, I have the gut feeling that this won't work on Linux as it is referring directly rc.exe.
Correct me if I'm wrong. It would be such a relief.

Investigating further, the closest Linux app that I found is some wrc in wine, but that has Linux style options using hyphen -I, -fo instead of Windows style slash /I, /fo

$ wrc --help
Usage: wrc [options...] [infile[.rc|.res]]
   -D, --define id[=val]      Define preprocessor identifier id=val
   --debug=nn                 Set debug level to 'nn'
   -E                         Preprocess only
   -F TARGET                  Ignored, for compatibility with windres
   -fo FILE                   Synonym for -o for compatibility with windres
   -h, --help                 Prints this summary
   -i, --input=FILE           The name of the input file
   -I, --include-dir=DIR      Add dir to the include search path (multiple -I allowed)
   -J, --input-format=FORMAT  The input format (either `rc' or `rc16')
   -l, --language=LANG        Set default language to LANG (default is neutral {0, 0})
   -m16                       Build a 16-bit resource file
   --nls-dir=DIR              Directory containing the NLS codepage mappings
   --no-use-temp-file         Ignored for compatibility with windres
   --nostdinc                 Disables searching the standard include path
   -o, --output=FILE          Output to file (default is infile.res)
   -O, --output-format=FORMAT The output format (`po', `pot', `res', or `res16`)
   --pedantic                 Enable pedantic warnings
   --po-dir=DIR               Directory containing po files for translations
   --preprocessor             Specifies the preprocessor to use, including arguments
   -r                         Ignored for compatibility with rc
   --sysroot=DIR              Prefix include paths with DIR
   -U, --undefine id          Undefine preprocessor identifier id
   --use-temp-file            Ignored for compatibility with windres
   -v, --verbose              Enable verbose mode
   --verify-translations      Check the status of the various translations
   --version                  Print version and exit

[karandit]

The same issue can be reproduced with the upcoming tauri-build = "1.3" (branch release/version-updates, commit 231c170276c2122cda30245cb012a7e6b1789ccd)

I suppose because it uses the same tauri-winres = "0.1"

[FabianLars]

Since you're using msvc on unix i'd imagine you read this pr description? #5788

If so, did you also scroll down to this comment #5788 (comment) which says you'll also need to do sudo apt install binutils-mingw-w64 (or however you'd add that package in your env)

[Guiguiprim]

Yes I did found out that the project moved from winres to tauri-winres, so I guess the issue must be in the changes made between the original crate and the fork.

I'm looking into it.

[FabianLars]

so I guess the issue must be in the changes made between the original crate and the fork.

The fork was made to support cross compilation (with the msvc toolchain) in the first place, upstream winres only support gnu on non-windows hosts.
That said, it's totally possible i messed something up, but i wasn't able to repro this issue on my system so far.

[Guiguiprim]

@FabianLars I did not read that PR description, I will.

But it still feels like a regression.

[Guiguiprim]

Maybe @karandit has an easy to share reproducible setup ?

Mine is a bit hard to minimized (it involves a complex nix environment config, done by a coworker, and I'm not sure I would be able to clean it down...)

[FabianLars]

But it still feels like a regression.

Hmm, i don't think so, prior to 1.3 the resource compiler wasn't invoked at all if you used the msvc toolchain on unix so your exe was actually a bit broken but at least the compilation didn't fail.
That said, starting with 1.2 or 1.3, can't remember, the exe will fail to start if you have tauri's dialog feature enabled without the resource compiler doing its job so imo failing at build time is good, but maybe the errors should be better.

[FabianLars]

btw i'll write a (experimental) guide for unix to windows (meaning linux & macos, nothing nix/nixos specific) shortly after the 1.3 release when the initial support for it on tauri's side is actually published. We'll keep communicating that this isn't really officially supported so that people keep using native hosts (including ci) to compile their apps for now.

[karandit]

heyyy, good news, it's working

@FabianLars I've read the mentioned PR, but I skipped that specific comment.

Based on that:

• I've installed apt install binutils-mingw-w64
• after that I got a missing dependency sh: 1: x86_64-w64-mingw32-gcc: not found.
• I had to apt install gcc-mingw-w64-x86-64
  and ta-da:

   Compiling reproduce-bug v0.0.0 (/usr/src/examples/reproduce-bug/src-tauri)
    Finished release [optimized] target(s) in 19.88s
        Warn Cross-platform compilation is experimental and does not support all features. Please use a matching host system for full compatibility.
        Warn ignoring WindowsMsi
        Warn NSIS directory is missing some files. Recreating it.
        Info Verifying NSIS package
 Downloading https://github.com/tauri-apps/binary-releases/releases/download/nsis-plugins-v0/NSIS-ApplicationID.zip
        Info extracting NSIS ApplicationID plugin
       Error failed to bundle project: `No such file or directory (os error 2)`

This is some other error fixed already.

[Guiguiprim]

Ok, so I might only need to update my nix environment.

I'm going to look into it. But I know that we are using a clang toolchain not a gcc one, so I might need some more tweaking.

[FabianLars]

I had to apt install gcc-mingw-w64-x86-64

That's a bit weird, binutils-mingw-w64 is supposed to contain both x86 and x64 but whatever, i'll keep that in mind for the guide, thanks :)

[FabianLars]

But I know that we are using a clang toolchain not a gcc one, so I might need some more tweaking.

I do too, and the upcoming guide will ask users to do that too. That's exactly why we forked winres, to support clang etc and not just gcc :)

[Guiguiprim]

With the clang toolchain we should probably use llvm-rc (that what I have elsewhere where embed-resource is used).

Maybe we could take some inspiration on the compiler resolution done in embed-resource:

• allow user define rc path using environment variables
• try to use llvm-rc

llvm-rc does need some specific call adaptation.

[Guiguiprim]

Something I do find weird in tauri-winres

• if compiled for windows, it chose from either compile_with_toolkit_gnu() or compile_with_toolkit_msvc() here
• if not compiled for windows it uses compile_with_toolkit_gnu() inside of which some check for msvc are done

I feel like it should always chose between compile_with_toolkit_gnu() or compile_with_toolkit_msvc(), and maybe improve compile_with_toolkit_msvc() cross compile support (I tried the easiest solution with the environment variable with success)

[FabianLars]

With the clang toolchain we should probably use llvm-rc (that what I have elsewhere where embed-resource is used). [...]

i wasn't aware of llvm-rc when i forked winres (try googling for that lol), but now that i see the extra steps they do with cc i'm happy i didn't because i 100% would have messed that up back then 😂

But for sure something we should look into for a follow-up release. v1.3 is locked already and since you can use mingw's resource compiler just fine from what i've seen so far it should be fine for this release at least.

We could also think about swapping winres for embed-resource altogether for v2 -> Honestly would really like that, i'm not really a fan of having to maintain a winres fork.

Something I do find weird in tauri-winres [...]

Oh yeah you shouldn't look at the fork if you wanna keep your sanity lol. I just went with "It's ugly but it works and is easy". I really just bolted the absolute minimum on top of it for tauri's use-case to make the nsis-on-linux poc work.
And of course i had no idea about that stuff so i just threw together something that didn't seem to break anything, while ignoring the fact that winres is for windows targets anyway...

[Guiguiprim]

OK, I'm going to try to do a PR to migrate to embed-resource if that something you are going to accept.

[FabianLars]

This would not be my decision, so let's ping @lucasfernog before we risk wasting your time.

[Guiguiprim]

APIs wise embed-resource only give compilation, winres also give resource file creation which is used.
So we would need either winres for creation and embed-resource for compilation or do the creation ourselves (or using an dedicated crate).

[FabianLars]

Yeah, i'm aware of that. I was thinking we could handle it similar to the WiX templates where Tauri provides a default but users can provide a modified template. idk, might need a bit more thinking and well, we don't have to switch to embed-resource if we can't think of a good api or it would end up in more work than just polishing up the winres fork a bit (which i probably have to do for 1.X anyway...).

[lucasfernog]

I would love to skip yet another fork (and if embed-resource works better, that's awesome). If it fixes our problems I don't see a reason for not taking it (and it seems well maintained, that's weird 😂 )

[Guiguiprim]

This is fixed in 2.0.0-alpha.5 (se tauri-apps/winres#8 (comment))