[bug] Failed to build Tauri application library on GNU toolchain (Windows)

[fibremint]

Describe the bug

As of a structure of the rust side project in Tauri application changed from single main.rs to the separated lib.rs and main.rs (e.g. tauri/examples/api), experiencing issues when building application on GNU toolchain (MSVC is fine).

Reproduction

1. Clone Tauri repository
2. Move to examples/api/src-tauri
3. Build application with cargo build

Expected behavior

Build Tauri application library (src-tauri/src/lib.rs) without any of errors that related to the library linking modifiers.

Platform and versions

[✔] Environment
    - OS: Windows 10.0.22621 X64
    ✔ WebView2: 112.0.1722.39
    ✔ MSVC: Visual Studio Community 2022
    ✔ rustc: 1.68.0 (2c8cc3432 2023-03-06)
    ✔ Cargo: 1.68.0 (115f34552 2023-02-26)
    ✔ rustup: 1.25.2 (17db695f1 2023-02-01)
    ✔ Rust toolchain: stable-x86_64-pc-windows-gnu (environment override by RUSTUP_TOOLCHAIN)
    - node: 19.6.0
    - yarn: 1.22.19
    - npm: 9.4.0

[-] Packages
    - tauri [RUST]: 2.0.0-alpha.8
    - tauri-build [RUST]: 2.0.0-alpha.4
    - wry [RUST]: 0.27.3
    - tao [RUST]: 0.18.3
    - @tauri-apps/api [NPM]: 1.2.0
    - @tauri-apps/cli [NPM]: 2.0.0-alpha.8

[-] App
    - build-type: bundle
    - CSP: img-src 'self' asset: https://asset.localhost blob: data:; default-src 'self' customprotocol: asset:; style-src 'unsafe-inline' 'self' https://fonts.googleapis.com; font-src https://fonts.gstatic.com
    - distDir: ../dist
    - devPath: http://localhost:5173/
    - framework: Svelte
    - bundler: Vite

Stack trace

// $ cargo build -vv
[api 0.1.0] cargo:rerun-if-changed=C:\Users\fibremint\repo\tauri\examples\api\src-tauri\../../.icons/32x32.png
[api 0.1.0] cargo:rerun-if-changed=C:\Users\fibremint\repo\tauri\examples\api\src-tauri\../../.icons/128x128.png
[api 0.1.0] cargo:rerun-if-changed=C:\Users\fibremint\repo\tauri\examples\api\src-tauri\../../.icons/128x128@2x.png
[api 0.1.0] cargo:rerun-if-changed=C:\Users\fibremint\repo\tauri\examples\api\src-tauri\../../.icons/icon.icns
[api 0.1.0] cargo:rerun-if-changed=C:\Users\fibremint\repo\tauri\examples\api\src-tauri\../../.icons/icon.ico
[api 0.1.0] cargo:rerun-if-changed=C:\Users\fibremint\repo\tauri\examples\api\src-tauri\../../.icons/tray_icon_with_transparency.png
[api 0.1.0] cargo:rerun-if-env-changed=TAURI_CONFIG
[api 0.1.0] cargo:rerun-if-changed=tauri.conf.json
[api 0.1.0] cargo:rustc-cfg=desktop
[api 0.1.0] cargo:rustc-env=TAURI_ANDROID_PACKAGE_PREFIX=com_tauri
[api 0.1.0] cargo:rustc-cfg=dev
[api 0.1.0] cargo:rustc-env=TAURI_TARGET_TRIPLE=x86_64-pc-windows-gnu
[api 0.1.0] package.metadata does not exist
[api 0.1.0] cargo:rustc-link-search=native=C:\Users\fibremint\repo\tauri\examples\api\src-tauri\target\debug\build\api-649bcb1147667a92\out
[api 0.1.0] cargo:rustc-link-lib=static:+whole-archive=resource

   Compiling api v0.1.0 (C:\Users\fibremint\repo\tauri\examples\api\src-tauri)
error: the linking modifiers `+bundle` and `+whole-archive` are not compatible with each other when generating rlibs

error: could not compile `api` due to previous error

Additional context

Here are some tries to build application:

1. Modify native library (resource) link modifiers
   Rust native-link-modifiers RFC says, +bundle is default for linking static libraries. And this would be lead to set link modifiers on link resource library to +bundle and +whole-archive.

       So I tried to set -bundle link modiers explicitly on winres/ilb.rs with cargo:rustc-link-lib=static:-bundle,+whole-archive=resource.

       And it seems to build without library link issues, enroll resources (icon and metadata) to the app and run without errors .

2. Use feature
   If resource static library have to be linked with +bundle and +whole-archive link modifiers, append #![feature(packed_bundled_libs)] to the top of src-tauri/lib.rs.

       This seems to work, but it requires nightly rust toolchain to build.

Related topcis:

• Linking modifier whole-archive and link time cfg are not supported on bundled static libraries
• Tracking Issue for feature(packed_bundled_libs)
• Whole archive modifier for native libraries is not propagated to final output
• Tracking Issue for linking modifiers for native libraries

[FabianLars]

Just a small heads-up: The gnu toolchain is not officially support in Tauri on Windows, so this may take a little while until it's fixed.

And fwiw, here's a relevant issue in a sister-fork of winres: BenjaminRi/winresource#7

And maybe this PR can resolve this issue too: tauri-apps/winres#8, but i didn't have time to look at that pr yet so i'm not sure.

Edit: Thanks for the extensive report btw!!

[fibremint]

Oh I get it. I would stick to the MSVC toolchain as of now.

And thank you for your contributions and works on Tauri too :)

[AlexTMjugador]

tauri-winres v0.1.1 caused a regression in my CI workflow, which tries to build for the Windows GNU target on a Windows host.

Downgrading tauri-winres to v0.1.0 with cargo update -p tauri-winres --precise 0.1.0 fixed my regression.

[FabianLars]

@AlexTMjugador Any particular reason you're using the gnu toolchain on a windows host? Like is there a rust dependency that only works with it for example? I'm asking because we're mostly going with "Only the msvc toolchain is supported" so i'm collecting data to see how far we'll get with that approach :)

I'll look into the regression either way, just a bit weird that it worked fine for me locally before i published it so it may take some time. Thanks for reporting the issue btw.

[AlexTMjugador]

Any particular reason you're using the gnu toolchain on a windows host? Like is there a rust dependency that only works with it for example? I'm asking because we're mostly going with "Only the msvc toolchain is supported" so i'm collecting data to see how far we'll get with that approach :)

I'd like to keep using the GNU toolchain to generate Windows executables in my project for several reasons:

• The GNU toolchain links against system DLLs (namely, an unversioned msvcrt.dll) which are practically guaranteed to be present on every Windows system. The MSVC toolchain, on the other hand, tends to link against versioned CRT DLLs that must be present on end-user systems for the binaries to work, making distribution more difficult.
  • MSVC binaries can link to the universal CRT instead, but that CRT is only available on fairly recent Windows environments, and getting that linking right is complex (iirc Tauri has quite a bit of custom build logic to make it work).
  • Linking statically to the CRT is technically possible but weird and complex.
• My application is also distributed as a CLI binary, which obviously doesn't use Tauri, so it can't take advantage of its custom build logic, and I'd like to avoid doing it myself or distributing binaries with different CRT requirements.
• My development workstation runs Linux, and I find the GNU toolchain more pleasant to use because it makes Windows feel less like the weird OS that does things in a completely different way (I'm aware that macOS uses clang, but the differences don't matter for my purposes, unlike with MSVC).
• My project used GStreamer not so long ago, and it required a special GStreamer plugin that was only available on the GNU redistributables, so I couldn't use the MSVC toolchain even if I wanted to. That's no longer a requirement, but my project still depends on several C libraries, so having a single compiler for all my supported platforms really makes it easier to troubleshoot build issues. Also, if my project's C dependencies grow in the future, my experience has shown that they're more likely to work better with the GNU toolchain.
• Using similar compilers with similar settings should result in similar code generation. This is important to me because my project is a compute-intensive app, and I'd like to have predictable, similar performance across platforms. MSVC code generation has improved a lot over time, and is now considered equivalent to GCC or Clang for most purposes, but I don't really want to take any risks, spend time fine-tuning compiler options for a subset of platforms, or have compiler-specific performance issues.

My experience using Tauri with the GNU toolchain on Windows has been relatively painless so far compared to the problems I had with MSVC, so I consider this a win, even if Tauri doesn't officially support it yet 😉

Also, Tauri is so close to having perfect GNU toolchain support on Windows that it seems worthwhile from the Tauri project's point of view to support it a bit more, but of course I'm not the right person to decide that.

Thanks for reporting the issue btw.

No problem! ❤️ Thanks to you and your team for providing such an awesome framework for GUI applications. I hope that my reply was insightful, even though it's a bit long-winded 😅

[FabianLars]

Thanks for the throughout response!!

In the meantime i figured out why i wasn't able to reproduce it. This line made me think i'd have to do rustup toolchain default stable-gnu but what's actually happening in your CI is that it uses the MSVC toolchain and cross-compiles to the gnu abi (set via the CARGO_BUILD_TARGET env var) -> noticed that because of the C:\\Users\\runneradmin\\.rustup\\toolchains\\nightly-x86_64-pc-windows-msvc\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib path in the error.

This means that a) i think v0.1.0 of our winres fork only worked because of a bug in my rushed implementation and that b) this may be out of scope for the embed-resource resource crate if i interpret this right: nabijaczleweli/rust-embed-resource#48 (comment).

Genuine question: Do you think msvc->gnu is something worth to fix or should we just require the gnu toolchain for the gnu target? Genuine question as i'm not sure if msvc->gnu has many actual use-cases. Your description sounded more like your actual intention is to use the gnu toolchain, and probably use it locally too, not just the target.

[AlexTMjugador]

Do you think msvc->gnu is something worth to fix or should we just require the gnu toolchain for the gnu target? Genuine question as i'm not sure if msvc->gnu has many actual use-cases. Your description sounded more like your actual intention is to use the gnu toolchain, and probably use it locally too, not just the target.

Oh, sure! I didn't want to cross-compile from MSVC to GNU here, that was a mistake from my part. As you can see my CI workflow is pretty complex and it could benefit from some simplification/refactoring, but that's on me. I don't think I'll ever need MSVC -> GNU cross-compiling support.