0

I am trying to rebuild existing C++ code for the ARM64 platform using Visual Studio 2022. (The build works well for the x86 and x64 platforms.) Most of the compilation succeeds but for one file that uses some Win32 API calls. I am getting dozen messages like

Error   C3861   '_InterlockedIncrement': identifier not found
Error   C3861   '_InterlockedExchangeAdd': identifier not found
Error   C3861   'WriteRelease8': identifier not found
Error   C3861   'WriteNoFence8': identifier not found
... 

I do use some of these functions (in particular InterlockedIncrement - no underscore), but not all of them. They are declared in WinNT.h, included via Windows.h.

To investigate, I have recreated a dummy project from scratch that includes Windows.h and references InterlockedIncrement. This compiles seamlessly. I have compared all build settings, including all paths (VC++ Directories), and could not find any significant difference.

I am also getting

1>C:\Program Files\Microsoft Visual Studio\2022\Community\MSBuild\Microsoft\VC\v170\Microsoft.CppBuild.targets(514,5):
 warning MSB8028: The intermediate directory (ARM64\Release\) contains files shared from another project (Formats.vcxproj).  This can lead to incorrect clean and rebuild behavior.

1>C:\Program Files\Microsoft Visual Studio\2022\Community\MSBuild\Current\Bin\amd64\Microsoft.Common.CurrentVersion.targets(2301,5):
warning MSB3270: There was a mismatch between the processor architecture of the project being built "" and the processor architecture of the reference "System.Data", "AMD64". This mismatch may cause runtime failures. Please consider changing the targeted processor architecture of your project through the Configuration Manager so as to align the processor architectures between your project and references, or take a dependency on references with a processor architecture that matches the targeted processor architecture of your project.

but I can't find the reason. I am not sure that this is directly related to the above problem. Note that the project is unmanaged C++ and has no reference, so that "the processor architecture of the reference "System.Data", "AMD64"" seems irrelevant.

What am I missing ?


Update:

I discovered hidden references in the project (not appearing in the IDE) and cleaned that. This solves the second issue. (The first remains.)

  • Can you provide a minimal reproducible example? – Minxin Yu - MSFT Jun 23 '22 at 09:24
  • @MinxinYu-MSFT: not shortly, the project is huge. –  Jun 23 '22 at 09:54
  • Hi ,glad to know you've found the solution to resolve this issue! Please consider accepting it as an answer to change its status to Answered. See [can I answer my own question..](https://stackoverflow.com/help/self-answer), Just a reminder :) – Minxin Yu - MSFT Jun 27 '22 at 01:21

1 Answers1

2

I finally found the cause. Here is how I proceeded:

  • I removed all files from the whole project, except the offending one (checked that the problem was still there);

  • I added that file to the dummy project (the problem was not showing there);

  • I compared the project files, but this told me nothing because they were too big and differ at numerous places;

  • I removed chunks from the file, each time recompiling, until the problem disappeared;

  • I understood that it was related to an #include <comdef.h> statement;

  • The original file (crippled with conditionals) was using an _ARM_ macro of mine to enable/disable some features for this platform.

  • After reducing the file to the single #include, I noticed that declaring the macro or not was enough to trigger the problem. Bingo !

It turns out that, though not documented, this macro is reserved by Microsoft and changes the behavior of the Windows includes.

The cure was just to use a non-conflicting macro.

  • Welcome to the world of [Machete Debugging](https://rootdirectory.de/doku.php?id=software:machetedebugging). This answer bears the seeds of a great "how to debug" tutorial. ;-) – DevSolar Jun 23 '22 at 15:27
  • 1
    BTW: The ARM doesn't have a XCHG instruction as x86 has. So there is no simple `InterlockedXxx` implementation for the platform. I found in WEC2013 kernel that the interrupt handler checks if the interrupted function is `InterlockedXxx` and simulates the behaviour. This obviously requires some special precautions in the headers, triggered by the `_ARM_` definition. – harper Jun 23 '22 at 15:43
  • @DevSolar: hahaha :-) I did not explain, but the troubleshooting was made harder by the fact that my macro was modifying the pieces of code that were compiled, so defining it or not created a jungle of errors and weird behaviors. –  Jun 23 '22 at 15:57
  • 1
    [identifiers starting with underscores are reserved](https://stackoverflow.com/q/228783/995714), especially ones that begin will an underscore followed by an uppercase character such as `_ARM_` – phuclv Jun 26 '22 at 01:56