Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Linker Error on Rust 1.50.0 #15

Closed
bmarcaur opened this issue Feb 26, 2021 · 4 comments
Closed

Linker Error on Rust 1.50.0 #15

bmarcaur opened this issue Feb 26, 2021 · 4 comments

Comments

@bmarcaur
Copy link

windres-rs version: 0.2.1
rust version: 1.50.0

Hello!

I have a simple build.rs file which contains:

        Build::new()
            .compile("bitmap.rc")
            .expect("Failed to set Windows resources");

where bitmap.rc is simply:

1 BITMAP "company-logo.bmp"

I am upgrading from 1.41.1 where this compiles without issue. After upgrading to 1.50.0 I am not getting something along the lines of:

= note: LINK : fatal error LNK1356: cannot find library `C:\...\target\i686-pc-windows-msvc\debug\build\APPLICATION-HASH\out\bitmap.res.lib' specified to be whole archived

Yet... that file does indeed exist in the location that is logged. If you look higher up in the logs you will see:

# These arguments
... "bitmap.res.lib" "/WHOLEARCHIVE:bitmap.res.lib" ... 
# And a libpath with this entry
... "/LIBPATH:C:\\...\\target\\i686-pc-windows-msvc\\debug\\build\\APPLICATION-HASH\\out" ...

Doing some light searching I found this thread, https://users.rust-lang.org/t/linking-on-windows-without-wholearchive/49846, which seems to suggest removing static from the build.rs when linking lib's. However, this seems to be baked in to windres here, https://github.com/FaultyRAM/windres-rs/blob/master/src/msvc.rs#L99.

I am not sure that I fully understand the issue and I was wondering if you have any thoughts.

Sorry for the terse logs, this is in support of company work and I don't feel comfortable dumping more complete logs, but if it will help I can try to do some more scrubbing.

I am hesitant to do a PR that "just removes this" because it lacks understanding on my part, but I can do that as well if you think that is the right course of action.

Thank you, and LMK how I can facilitate.

@bmarcaur
Copy link
Author

I am gonna try and bisect exactly which version of rust this regressed as I do not think it is unique to 1.50.0.

@bmarcaur
Copy link
Author

bmarcaur commented Feb 26, 2021

Yeah seems to have regressed between 1.45.2 and 1.46.0.

Edit: I am kinda shocked that this behavior was left in the MSVC build chain as it really seems like it is a breaking change. The comments in this, rust-lang/rust#72785, seem to indicate that they are aware of cases where it might break and that the fix is outlined in an RFC where you can control this explicitly, yet... the actual implementation of that has yet to be started.

bors bot added a commit that referenced this issue Feb 26, 2021
16: Update to 0.2.2 r=FaultyRAM a=FaultyRAM

Addresses #15

Co-authored-by: FaultyRAM <316014+FaultyRAM@users.noreply.github.com>
bors bot added a commit that referenced this issue Feb 26, 2021
16: Update to 0.2.2 r=FaultyRAM a=FaultyRAM

Addresses #15

Co-authored-by: FaultyRAM <316014+FaultyRAM@users.noreply.github.com>
This was referenced Feb 26, 2021
@FaultyRAM
Copy link
Owner

Sorry for the notification spam, bors broke my PR 😞

Anyway, I published 0.2.2 which removes =static as suggested in the forum thread you linked. I haven't really looked into why whole archive linking breaks things on MSVC targets, I just hope that this is an edge case and it didn't silently break a ton of crates.

@bmarcaur
Copy link
Author

bmarcaur commented Feb 27, 2021

and it didn't silently break a ton of crates

I hope that as well 👀

Thank you for the prompt fix!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants