Click here to Skip to main content
16,021,226 members
Please Sign up or sign in to vote.
1.00/5 (1 vote)
See more:
I am the one who asked the question located here[^]

Someone said there that the program ran effortlessly on his computer. I became determined to eliminate all compilation errors. I converted all my sub-programs into modules because I suspected that the errors I was witnessing there were as a result of header file clash. I was able to reduce the errors into two. I thought hard on what to do next. Then I decided to create a new project with the same name and copy my files into it hoping it would solve the problem. I ended up with the same errors. The compiler output from Visual Studio is shown below. How do I solve it? This is taking too much time.

Build started...
1>------ Build started: Project: ResultSheets, Configuration: Debug x64 ------
1>Scanning sources for module dependencies...
1>AppTypes.ixx
1>AppTypesData.ixx
1>Address.ixx
1>AppErrMessage.ixx
1>C:\Program Files (x86)\Windows Kits\10\Include\10.0.22621.0\um\winnt.h(169,28): fatal  error C1189: #error:  "No Target Architecture"
1>ArmInfo.ixx
1>ClassInfo.ixx
1>ClassResult.ixx
1>C:\Program Files\Microsoft Visual Studio\2022\Community\MSBuild\Microsoft\VC\v170\Microsoft.CppCommon.targets(486,5): warning MSB8074: Cannot read Module Dependencies file x64\Debug\AppErrMessage.ixx.module.json: Expecting element 'root' from namespace ''.. Encountered 'None'  with name '', namespace ''.  The build order might be incorrect.
1>Compiling...
1>AppErrMessage.ixx
1>Current.ixx
1>AppTypes.ixx
1>Address.ixx
1>C:\Users\HP\source\repos\ResultSheets\Current.ixx(3,22): warning C5201: a module declaration can appear only at the start of a translation unit unless a global module fragment is used
1>C:\Users\HP\source\repos\ResultSheets\Address.ixx(3,22): warning C5201: a module declaration can appear only at the start of a translation unit unless a global module fragment is used
1>C:\Program Files (x86)\Windows Kits\10\Include\10.0.22621.0\um\winnt.h(169,1): fatal  error C1189: #error:  "No Target Architecture"
1>Done building project "ResultSheets.vcxproj" -- FAILED.
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========
========== Build started at 1:45 AM and took 17.624 seconds ==========


Some one on stackoverflow had a similar problem stated here.

Can anyone explain the solution there to me?


UPDATE:
I was able to discover the lines of code that were causing the error. It is this set pf lines in winnt.h:

C++
#if defined(_AMD64_) || defined(_X86_) || defined(_ARM64EC_)
#define PROBE_ALIGNMENT( _s ) TYPE_ALIGNMENT( DWORD )
#elif defined(_IA64_) || defined(_ARM_) || defined(_ARM64_)

//
// TODO: WOWXX - Unblock ARM. Make all alignment checks DWORD for now.
//

#define PROBE_ALIGNMENT( _s ) TYPE_ALIGNMENT( DWORD )
#elif !defined(RC_INVOKED)
#error "No Target Architecture"
#endif


What I have tried:

I have been Googling for days, but have not come up with a solution yet.
Posted
Updated 24-Oct-23 2:59am
v8
Comments
Gbenbam 22-Oct-23 4:13am    
Are you really sure about that because seem to remember intstlling all there was to install.
[no name] 22-Oct-23 3:26am    
Why do all your source files have the .ixx extension? Are they some special source language?
Gbenbam 22-Oct-23 4:11am    
That is the extension for module files in visual studio 2022
[no name] 22-Oct-23 4:20am    
Sorry, but I have no experience of using modules. Why do you think this is the way to solve your original problem?
Gbenbam 22-Oct-23 4:57am    
I think it is caused by header files class. When one or more files include the same header file. Modules only exposed exported component of the file. So, the don't create header file clash.

I think your "solution" just side-stepped the problem because if you have not specified a target architecture it will cause an error later depending on what API functions you end up calling. You can do that by opening the project's Properties dialog and going to the Linker section and the Advance page. There is a setting labelled, "Target Machine" and that is what needs to be set. I usually select MachineX64 but there are other options available like X86 and ARM.
 
Share this answer
 
Comments
Gbenbam 22-Oct-23 12:59pm    
OK. I will check it out.Thanks a lot.
Gbenbam 22-Oct-23 13:17pm    
I am sorry, I don't think you are right.When I got to the complier setting location, I saw that it was already set to x64. Just as I had chosen in the combobox on the toolbar of visual studio where you can choose either x86 or x64.I went back and changed the option to x86 on visual studio's toolbar combox, then went back to see what the compiler option now is. It had changed to x86. So, whatever you choose at the toolbar combobox is your target machine , and I always have a choice on the tool bar which is either x86 or x64.
Gbenbam 22-Oct-23 17:01pm    
Well, I eventually confirmed that you are right. The code that had <stringapiset.h> in it, and from which I eventually commented out MultiByteToWideChar and its sister function from, I decided to make a dll of the code since I still needed the conversion from utf8 to utf16. I beleived that making it a dll would solve the problem because it would be all alone. Well, to the greatest of surprise, the #error notification showed up as a compilation error again. This was so exasperating. I had no other option than to go and and attempt to set the target platform like you stated in your solution. First, I set it to x86. The compiler complained that x86 was not compartible with x64 .By that I guessed that it was referring to x64 that I had chosen on combobox of visual studio that is located on the toolbar. So, I changed the setting of the one on the toolbar to x86 too. I was plesantly surprised to discover that it worked.

So, I went back to my original project and uncommented everything I had commented out to exclude MultyBteToWideChar ant its sister from my project. Then, I went to the compiler settings and set the target platform to x64. I was quite happy to discover that the project compiled without any #error compilation error. Your solution is the correct solution. I noticed that my own solution has been accepted. Plese, moderators, this solution is the correct one.It is the best. Kindly delete mine and let people use this. Mine will cause people a lot of stress. I am accepting this your elegant solution right away. What you said proved to be true. My solution was a side-stepping. The problem occurred again in a situation where there ws no room for side-stepping. It was your solution that saved the day. By the way, I abandoned the dll that I created. It was no longer useful to me because of your solution.What anyone who faces this kind of error needs to do is to first flip the default target platform in the compiler setting and the chose his prefferd one. Once you choose apply, the problem is solved.

Please, moderators, this solution should be top rated and not mine. I am the one who came with the problem and I know the better solution because I have applied both.
The problem is caused as a result of several files clashes.
It is caused as a result of several files #including winnt.h along with the existing ones. Someone on stack overflow mentioned casually that he once had the problem when he #include
stringapiset.h
to his project. I had the header file in an header file that contained functions for converting to utf8 to utf16 and vice versa. The functions use MultiButeToWideChar fuction and its sister WideCharToMultibyte function. So, I decided to unplug the function fom my app. I commented out
WidCharToMultibyte
and its sister from the function to see what will happen. Shockingly, that sovled the problem.

So, if you have such a problem in the future consider files that #include winnt.h to the build system and find a way to resolve the clash.
 
Share this answer
 
v4

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)



CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900