-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
Add an alias object to the import lib #2734
Conversation
This is enabled on x86 and x64 only, as it relies on a MASM assembly file, still, it's not actually assembly, there's no _code_ generated, just objects with the correct sections. whoops fix
…ze without doing anything special.
This is so the mangling is right.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is "approve with suggestions": I wouldn't be upset if we merge and cleanup my nitpicks later since this is high priority.
@CaseyCarter I pushed minor changes after you approved. @barcharcraz Thank you for fixing this! 😻 I had no idea the assembler could be used to achieve this. |
I have filed https://gitlab.kitware.com/cmake/cmake/-/issues/23537 'MSVC assembler shows "Assembling" messages that should be suppressed'. |
I'm mirroring this to the MSVC-internal repo - please notify me if any further changes are pushed. |
✅ 🎉 😸I have verified the end-to-end scenario for both x86 and x64. I built a program using |
I've pushed changes to add this to MSBuild. |
|
Thanks for fixing this major bug that I wrote! 🐞 😻 🛠️ |
Co-authored-by: Stephan T. Lavavej <stl@microsoft.com>
@@ -176,6 +176,18 @@ SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception | |||
</BuildFiles> | |||
</ItemGroup> | |||
|
|||
<ItemGroup Condition="'$(BuildArchitecture)' == 'i386' or '$(BuildArchitecture)' == 'amd64'"> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems like this only fixes this for x86 and x64 but not for arm64?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The aliases are not needed on ARM64 IIRC, this is for backwards compatibility on x86/x64 with code that predates ARM64 support. Are you having an issue building some ARM64 code?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes I have the same LNK2019: unresolved external symbol errors on ARM64 and have applied the AlternateName workaround for arm64 for now.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd recommend opening a new issue with repro steps then. Are you targetting ARM64EC with some old x64 binary?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a normal ARM64 static library similarly compiled before this change went in, causing the exact same symptoms after this change when included in a dll targeting ARM64.
We used to use an internal "aliasobj" tool to generate this object, but it would be a ton of work to release it. Thus, we switched to using
/ALTERNATENAME
, however we put that in the directives section of xonce2.cpp with a static init function call pointing there from shared mutex. This was a problem because if you compile with an old toolset but later link with a new toolset the linker has no way of knowing it should be pulling in the new xonce2.cpp.This keeps the /ALTERNATENAME directives (though they could later be removed, I suppose) but additionally adds an alias object (alias.asm.obj) to the import library that contains "real" weak external symbols.
This generates an object file that's very similar to what aliasobj would have done, except there's only one object, instead of one per symbol (I think this is fine), and the object is more "complete" (it contains debug info, and a .text section (that's empty) and so on).
The cmake has been updated quite extensively to specify options for the correct language. I only bothered to do this for the options that actually make it to the implib objects compilation.
A simple test has been added, this test uses it own prefix with just the
/Mxx
options.Fixes #2655