Compiling with x86_64-pc-windows-gnu fails

[Zerowalker]

As far as i can tell it should work as it seems to be supported, if not them i apologize for bringing it up.

When i compile with this target it fail with this:

.....\resource-test\target\x86_64-pc-windows-gnu\release\build\resource-test-98a4ca788ea587fc\out/resource-test-manifest.lib: file not recognized: file 
format not recognized
          collect2.exe: error: ld returned 1 exit status

Find it a bit odd that it looks for a resource-test-manifest.lib but perhaps that's expected?

My build.rs dynamically generates the rc and manifest with the right name cause i am lazy.
I will provide them below in case it matters.

build.rs

extern crate embed_resource;

macro_rules! name {
    () => {
        env!("CARGO_PKG_NAME")
    };
}
const DATA_MANIFEST_VERSION: &str = r#"<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0" xmlns:asmv3="urn:schemas-microsoft-com:asm.v3">
<assemblyIdentity
    version="1.0.0.0"
    processorArchitecture="*"
    name="CompanyName.ProductName.YourApplication"
    type="win32"
/>
<description>Your application description here.</description>
<dependency>
    <dependentAssembly>
        <assemblyIdentity
            type="win32"
            name="Microsoft.Windows.Common-Controls"
            version="6.0.0.0"
            processorArchitecture="*"
            publicKeyToken="6595b64144ccf1df"
            language="*"
        />
    </dependentAssembly>
</dependency>
   <asmv3:application>
		<asmv3:windowsSettings>
			<longPathAware xmlns="http://schemas.microsoft.com/SMI/2016/WindowsSettings">true</longPathAware>
		</asmv3:windowsSettings>
	</asmv3:application>
</assembly>"#;
const PATH_MANIFEST_RC: &str = concat!(name!(), "-manifest.rc");

macro_rules! PATH_EXE_MANIFEST {
    () => {
        concat!(name!(), ".exe.manifest")
    };
}
const DATA_EXE_MANIFEST: &str = concat!(
    "#define RT_MANIFEST 24\r\n1 RT_MANIFEST \"",
    PATH_EXE_MANIFEST!(),
    '\"'
);
fn main() {
    std::fs::write(PATH_MANIFEST_RC, DATA_EXE_MANIFEST).unwrap();
    std::fs::write(PATH_EXE_MANIFEST!(), DATA_MANIFEST_VERSION).unwrap();

    embed_resource::compile(PATH_MANIFEST_RC);
}

RC

#define RT_MANIFEST 24
1 RT_MANIFEST "resource-test.exe.manifest"

Manifest

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0" xmlns:asmv3="urn:schemas-microsoft-com:asm.v3">
<assemblyIdentity
    version="1.0.0.0"
    processorArchitecture="*"
    name="CompanyName.ProductName.YourApplication"
    type="win32"
/>
<description>Your application description here.</description>
<dependency>
    <dependentAssembly>
        <assemblyIdentity
            type="win32"
            name="Microsoft.Windows.Common-Controls"
            version="6.0.0.0"
            processorArchitecture="*"
            publicKeyToken="6595b64144ccf1df"
            language="*"
        />
    </dependentAssembly>
</dependency>
   <asmv3:application>
		<asmv3:windowsSettings>
			<longPathAware xmlns="http://schemas.microsoft.com/SMI/2016/WindowsSettings">true</longPathAware>
		</asmv3:windowsSettings>
	</asmv3:application>
</assembly>

[nabijaczleweli]

Hm, I can't repro this? Odder still, glibc targets should have a normal object archive libresource-testresource-test-manifest.a (and, for me, this does), not .libs?

You should only get .lib if #[cfg(all(target_os = "windows", target_env = "msvc"))] (and, crucially, we managed to find VS toolchain) (otherwise (#[cfg(all(target_os = "windows", not(target_env = "msvc")))]) a normal windres toolchain). Are you cross-compiling at all? Does your Cargo.lock have winreg and/or vswhom in it? What does file say about the .lib?

[Zerowalker]

oh wait that might be it.
I am building on windows and targeting gnu, if that's not taken into account it make sense it assumes it's msvc then and looks for .lib

[nabijaczleweli]

I have a native glibc toolchain:

>rustup target list | grep installed
x86_64-pc-windows-gnu (installed)

>rustc --print cfg
debug_assertions
panic="unwind"
target_arch="x86_64"
target_endian="little"
target_env="gnu"
target_family="windows"
target_feature="fxsr"
target_feature="sse"
target_feature="sse2"
target_has_atomic="16"
target_has_atomic="32"
target_has_atomic="64"
target_has_atomic="8"
target_has_atomic="ptr"
target_os="windows"
target_pointer_width="64"
target_vendor="pc"
windows

This works as-expected and is explicitly supported. Are you cross-compiling from -msvc to -gnu? That may be unsupportable; what does file say about the .lib?

[Zerowalker]

i am on windows, i am compiling with x86_64-pc-windows-gnu.
so there's no cross-compiling, on windows for windows, i am just not using compiling with msvc,
though i do have the toolchain installed.

arm-unknown-linux-gnueabihf (installed)
armv7-unknown-linux-gnueabihf (installed)
i686-pc-windows-msvc (installed)
x86_64-pc-windows-gnu (installed)
x86_64-pc-windows-msvc (installed)
x86_64-unknown-linux-gnu (installed)

Here's a repo: https://github.com/Zerowalker/resource-test
running with cargo build --target x86_64-pc-windows-gnu fails with the error.

[nabijaczleweli]

Cannot reproduce, so I think you are cross-compiling – does cargo +stable-x86_64-pc-windows-gnu build (substitute the stable- with the relevant version from rustup toolchain list) work?

[Zerowalker]

it seems to work when i do that. I am a bit confused, what am i missing here?

EDIT: is it cause i specify the toolchain?
normally it seems to just use the same toolchain as the target when it's the same so i didn't think much of it.
Or at least that's what i thought was happening:s

[nabijaczleweli]

cargo build uses the default toolchain (stable-x86_64-pc-windows-msvc for you probably), so --target x86_64-pc-windows-gnu means you're cross-compiling for glibc. Build scripts are built for the host quad, because they run on the host, and your host is MSVC. This is problematic because the linker (for the target) doesn't understand the library.

If you spec cargo +stable-x86_64-pc-windows-gnu build you're building natively on glibc, for glibc, so the generated artifact makes sense for the linker.

[Zerowalker]

oh, had no idea, i have used them like they where the same.

Sorry for wasting your time.