Skip to content

Conversation

@cbezault
Copy link
Contributor

@cbezault cbezault commented Dec 1, 2020

Works towards #1504.

@cbezault cbezault added bug Something isn't working ARM ARM64 Related to the ARM64 architecture labels Dec 1, 2020
@cbezault cbezault requested a review from a team as a code owner December 1, 2020 18:17
@sylveon
Copy link
Contributor

sylveon commented Dec 1, 2020

AFAIK this only resolves the second case, where it can't find the Windows functions.

I don't think that the first broken case, which can't find __std_atomic_wait_direct and friends, will be fixed.

Copy link
Contributor

@CaseyCarter CaseyCarter left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm fine with this change but not with the suggestion that it completely fixes the linked bug - as @sylveon commented. There's some linker funkiness - either a bug in the ARM linker or some unsupported behavior on x86 that we're taking advantage of - that still needs addressing.

That said, I'd be happy to go ahead and approve this as an improvement that partially addresses but does not close #1504.


#if _ATOMIC_WAIT_ON_ADDRESS_STATICALLY_AVAILABLE

#pragma comment(lib, "synchronization")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I thought we had this comment, but it was replaced with linking using CMakeList.txt.
@BillyONeal , do you remeber anything relevant to this?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The final binary which links against the atomic_wait.obj needs to also know to link in the synchronization.lib. It is insufficient to just link against the synchronization.lib at build time.

Copy link
Contributor

@CaseyCarter CaseyCarter Dec 1, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It is insufficient to just link against the synchronization.lib at build time.

Do I understand correctly that this isn't a problem for x86/x64 because _ATOMIC_WAIT_ON_ADDRESS_STATICALLY_AVAILABLE is zero because they have to support Windows 7? (I should have asked this in my review instead of simply assuming.)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, _ATOMIC_WAIT_ON_ADDRESS_STATICALLY_AVAILABLE is zero on x86/x64

@cbezault
Copy link
Contributor Author

cbezault commented Dec 1, 2020

@CaseyCarter I updated the original issue with information concerning the linking issue. It appears to be a separate issue that I reached out to Jimmy to confirm.

@CaseyCarter CaseyCarter removed their assignment Dec 2, 2020
@StephanTLavavej StephanTLavavej self-assigned this Dec 2, 2020
@StephanTLavavej StephanTLavavej merged commit f47e123 into microsoft:master Dec 2, 2020
@StephanTLavavej
Copy link
Member

Thanks for fixing this linker error! Your fix will ship in VS 2019 16.9 Preview 3. 🚢 🐈

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

ARM64 Related to the ARM64 architecture bug Something isn't working

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants