windows-rs 0.23 is incompatible with embedded icons in resource files

[Jasper-Bekkers]

We're using the embed_resource crate to embed a resource file in our application, we're doing this mostly to set up our app icon;

#define IDI_ICON 0x101

IDI_ICON ICON "icon.ico"

#define RT_MANIFEST 24
#define APP_MANIFEST 1

APP_MANIFEST RT_MANIFEST breda.manifest

With this in our build.rs

    if std::env::var("CARGO_CFG_TARGET_OS").expect("target platform not set") == "windows" {
        embed_resource::compile("../../resources/windows.rc");
    }

However this seems to fail with the following error messages:

          CVTRES : fatal error CVT1100: duplicate resource.  type:ICON, name:1, language:0x0409
          LINK : fatal error LNK1123: failure during conversion to COFF: file invalid or corrupt

Does windows-rs embed it's own icon, or what's going on?

Fwiw: removing our call to embed_resource fixes this issue.

[riverar]

Hi @Jasper-Bekkers, can't seem to repro here. Here's a sample I put together https://github.com/riverar/wrs-repros/tree/master/issue-1256 that can help us start narrowing down the issue.

[riverar]

Closing this for now. @Jasper-Bekkers feel free to follow up here as needed. (Will also keep an eye on Traverse Research and Embark Studios, sounds like you're cooking up something good over there! 👀)

[Jasper-Bekkers]

I think the repro is not representative of our build setup, but I haven't been able to nail down exactly what's happening on our end. Needs further investigation, though I feel closing is a bit premature

[kennykerr]

Feel free to reopen once you have a repro to share.

[MarijnS95]

I have uncovered the problem on our end. embed_resource creates a library with the file stem of our resource - which is "conveniently" named windows.rc - resulting in windows.lib. Both embed_resource and windows-rs tell the linker to link dylib=windows: our resource library is found first and linked twice resulting in this duplication error (without even getting to the tons of linker errors for not finding windows-rs's windows.lib, that must be a later step in the linking process).

Renaming it to app.rc solves the issue, and explains why @riverar's repro doesn't repro the issue.

[riverar]

Nice sleuthing, thanks @MarijnS95!