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

Conflicting weak symbol definitions when linking windows-macros on Github CI #1006

Closed
qdot opened this issue Jul 27, 2021 · 2 comments
Closed
Labels
question Further information is requested

Comments

@qdot
Copy link

qdot commented Jul 27, 2021

When bringing in windows-macros in a crate and compiling it on Github Actions CI, I'm getting the following linking error:

libwindows_gen-474a14e06a135143.rlib(windows_gen-474a14e06a135143.windows_gen.3qcf9mth-cgu.3.rcgu.o) : fatal error LNK1227: conflicting weak extern definition for '_RNvXININtNtCsdw1U8rBUA7W_11windows_gen6squote9to_tokenss1_0pEINtNtCs3E5rcf10EnF_5alloc5boxed3BoxpENtB5_8ToTokens9to_tokensB9_'. New default '.weak._RNvXININtNtCsdw1U8rBUA7W_11windows_gen6squote9to_tokenss1_0pEINtNtCs3E5rcf10EnF_5alloc5boxed3BoxpENtB5_8ToTokens9to_tokensB9_.default._RINvMNtCstYrKh3qYsp_4core5sliceSNtNtCs3E5rcf10EnF_5alloc6string6String13get_uncheckedINtNtNtB5_3ops5range9RangeFromjEECsdw1U8rBUA7W_11windows_gen' conflicts with old default '.weak._RNvXININtNtCsdw1U8rBUA7W_11windows_gen6squote9to_tokenss1_0pEINtNtCs3E5rcf10EnF_5alloc5boxed3BoxpENtB5_8ToTokens9to_tokensB9_.default._RINvMNtCstYrKh3qYsp_4core5sliceSRe13get_uncheckedINtNtNtB5_3ops5range9RangeFromjEECsdw1U8rBUA7W_11windows_gen' in libwindows_gen-474a14e06a135143.rlib(windows_gen-474a14e06a135143.windows_gen.3qcf9mth-cgu.11.rcgu.o)

CI Status Link: https://github.com/deviceplug/btleplug/runs/3164475302?check_suite_focus=true

I can't seem to repro this on my local machine, so it may be something in our CI setup, but I'm not particularly sure what. We aren't caching anything that I'm aware of, so I don't think this is a conflict between versions or anything.

@kennykerr
Copy link
Collaborator

Weird. We run a lot of CI builds across windows-rs and windows-samples-rs and I've not seen this before. Perhaps @rylev or @ricobbe recognize something.

@kennykerr kennykerr added the question Further information is requested label Jul 27, 2021
@danielframpton
Copy link
Contributor

I think the issue is not with the particular crate but a general issue with coverage instrumentation as also seen in rust-lang/rust#85461.

The conflict appears to be between different codegen units in the same rlib, so you may have success setting -Ccodegen-units=1 as well as -Zinstrument-coverage for that build.

@qdot qdot closed this as completed Jul 28, 2021
anp added a commit to anp/moxie that referenced this issue Oct 30, 2021
anp added a commit to anp/moxie that referenced this issue Oct 30, 2021
anp added a commit to anp/moxie that referenced this issue Oct 30, 2021
* [ci] Bump toolchain version.

* [ofl] satisfy updated clippy

* [core] satisfy updated clippy

* [ci] don't regenerate lockfiles

for ofl, we want to pin the deps for the binary

the root lockfile is gitignored so shouldn't matter

* [dom] satisfy updated clippy

* [ci] stop installing gtar

the new version of the cache action defaults to it apparently

* [ofl] limit to 1 cgu when collecting coverage

workaround suggested in microsoft/windows-rs#1006 (comment)
bors bot added a commit to taiki-e/cargo-llvm-cov that referenced this issue Nov 13, 2021
101: Force 1 codegen unit r=taiki-e a=taiki-e

Workaround for rust-lang/rust#85461
See also microsoft/windows-rs#1006 (comment)

Co-authored-by: Taiki Endo <[email protected]>
bors bot added a commit to taiki-e/cargo-llvm-cov that referenced this issue Nov 13, 2021
101: Force 1 codegen unit on windows r=taiki-e a=taiki-e

Workaround for rust-lang/rust#85461
See also microsoft/windows-rs#1006 (comment)

Co-authored-by: Taiki Endo <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

3 participants