Problems encountered when the project moved from Mingw to MSVC 2017

kgsbt

My project havs used Mingw to compile.Set up as shown in the following figure：

Then，I use MSVC2017 to compile.

I get the error:

almost at these C + + standard libraries. How can I fix it？

jsulm

@kgsbt said in Problems encountered when the project moved from Mingw to MSVC 2017:

How can I fix it？

Do a complete rebuild: delete build folder, run CMake/QMake and build.
If you still have build errors then please post the first error as text not picture.

kgsbt

@jsulm I try to fix it.and I have clean and rebuild the project.
In my .pro file :
* INCLUDEPATH += $$PWD/include
and $$PWD/include/stdlib.h is for Mingw,so I use C:\Program Files (x86)\Windows Kits\10\Include\10.0.22621.0\ucrt\stdlib.h to replace $$PWD/include/stdlib.h.
The First error is :
D:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\VC\Tools\MSVC\14.16.27023\include\cstddef:101: error: C2874: using 声明导致“std::max_align_t”的多次声明

jsulm

@kgsbt said in Problems encountered when the project moved from Mingw to MSVC 2017:

$$PWD/include/stdlib.h

Why?!
Do you really have this header in your project folder?

JoeCFD

@kgsbt clean is not enough. Try to do it from command line. Do:
make distclean
in the build dir or
delete the whole build dir
then
rerun qmake
and build

kgsbt

@jsulm of course,the origin folder is in the picture left,and the stdlib.h is right.

I noted the stdlib.h seems like prepared for mingw,and I replaced the stdlib.h with C:\Program Files (x86)\Windows Kits\10\Include\10.0.22621.0\ucrt\stdlib.h.The folder now is:

Also I deleted the build folder,then clean and rebuild the project,the first is:
D:\Program Files (x86)\Microsoft Visual Studio\2022\BuildTools\VC\Tools\MSVC\14.16.27023\include\cstddef:101: error: C2874: using 声明导致“std::max_align_t”的多次声明

ChrisW67

@kgsbt You should not copy any part of your toolchain files into your project. Between your CMakeLists.txt/project PRO file and your tool chain's default behaviour they should all be found at build time in standard locations outside your project.

kgsbt

@JoeCFD I've tried deleting the build folder and rebuilding it, but it's not working

jsulm

@kgsbt said in Problems encountered when the project moved from Mingw to MSVC 2017:

but it's not working

Same problem or something else?
What Qt version do you use?

kgsbt

@ChrisW67 said in Problems encountered when the project moved from Mingw to MSVC 2017:

@kgsbt You should not copy any part of your toolchain files into your project. Between your CMakeLists.txt/project PRO file and your tool chain's default behaviour they should all be found at build time in standard locations outside your project.

Thanks to @ChrisW67 and @jsulm . I removed "INCLUDEPATH += $$PWD/my_include" in .pro file, and move some MATLAB dependency header file to my folder.Then it success!
But there is a new

error:D:\QtProjects\autotest\1026msvc\autotestsystem\AutoTestSystem\AcBoard\AcBoardEntity.h:304: error: C1060: 编译器的堆空间不足
And the AcBoardEntity.h looks like:

I try to :

add "QMAKE_CXXFLAGS += /Zm1000" to .pro file (tryed10-1000)
add "CONFIG += resources_big" to .pro file
it didn't work.

How can I fix this problem? Is it because the array is too big? I did run out of memory during compilation

JonB

@kgsbt said in Problems encountered when the project moved from Mingw to MSVC 2017:

C1060

This is indeed a compiler out of space error. I am not sure why allocating large arrays would affect the compiler rather than just runtime, but there you are. See https://learn.microsoft.com/en-us/cpp/error-messages/compiler-errors-1/fatal-error-c1060?view=msvc-170, which does include:

Eliminate unnecessary global variables, for example, by allocating memory dynamically instead of declaring a large array.

JoeCFD

@kgsbt

Here are some common stack size limits for different versions of Windows:
32-bit Windows: In 32-bit versions of Windows, the default stack size limit is typically 1 MB. This means that each thread in a 32-bit Windows process has a 1 MB stack by default.
64-bit Windows: In 64-bit versions of Windows, the default stack size is usually larger, often around 4 MB or more. The specific size can depend on the version and configuration.

Try to use 2/3D pointers to allocate memory to your arrays. You are using too much stack memory.

kgsbt

@JoeCFD said in Problems encountered when the project moved from Mingw to MSVC 2017:

Try to use 2/3D pointers to allocate memory to your arrays.

Yes！It works using 2/3D pointers.Thank you very much@JoeCFD!

kgsbt

Hi，guys!I have a new error :

C:\Program Files (x86)\Windows Kits\10\Include\10.0.22621.0\ucrt\complex.h:221: error: C2872: “clog”: 不明确的符号

There is no "clog" in my project. I just include <complex.h> .why this error?

JonB

@kgsbt
Don't know because you have not translated the message from Chinese for us to comment on....
You do not have to include a header file in your project for it to be included, and you do not have to use a token like clog for it to cause an error when included.

kgsbt

@JonB
it's:

C:\Program Files (x86)\Windows Kits\10\Include\10.0.22621.0\ucrt\complex.h:221: error: C2872: “clog”: ambiguous symbol

I only include complex.h here:

JonB

@kgsbt said in Problems encountered when the project moved from Mingw to MSVC 2017:

error: C2872: “clog”: ambiguous symbol

Google: error: C2872: “clog”: ambiguous symbol
https://stackoverflow.com/questions/54972981/how-can-i-resolve-the-occuring-ambiguity-when-using-clog-for-computing-the-natur ?

I haven't been able to reproduce this with gcc 7.3 without using namespace std but in general all functions from C headers reside in the global namespace. Therefore you should be able to resolve the ambiguity by prefixing clog with :::

Agreed, you must have a using namesapce std elsewhere - maybe in an included header?

This solved it, thanks. Yes, in one header I'm including it was used.

Can this apply to you?

I only include complex.h here:

Once again, this is not enough to show you will not have the problem. You show a header/include file, AcBoardWorkspace.h. That goes #include <complex.h>. But that does not tell us the whole story. It will #included somewhere, and that may be preceded by other #includes and/or using namespace statements, etc. You cannot keep looking at complex.h in isolation, you must look at it in the context of where it is being included.

kgsbt

@JonB
I searched "clog" in my project.
It's no found in my project:

so I can't use this way,I don't kown where to add "::" .
@JonB said in Problems encountered when the project moved from Mingw to MSVC 2017:

Therefore you should be able to resolve the ambiguity by prefixing clog with ::

kgsbt

@JonB thanks. I resolved this problem！
I put #include <complex.h> in The first line of AcBoardWorkspace.h. And put #include “AcBoardWorkspace.h” on the first line of the file that needs it.And it works！

JonB

@kgsbt
You were not supposed to be able to find clog in your own code --- it's in complex.h. And you were not supposed to deploy the solution to prefix it with :: as that would be in that file which you do not want to change.

I put #include <complex.h> in The first line of AcBoardWorkspace.h. And put #include “AcBoardWorkspace.h” on the first line of the file that needs it.And it works！

This is right. Something you have now moved it before in your #include files will have using namespace std. That will have made clog (without the ::) go wrong when complex.h got included. Now complex.h will be included before that std statement, and will allow it to work.

As a general guide: this does not always avoid any problems, but I arrange my #includes as far as possible:

First any "system" includes, which have nothing to do with Qt.
Next any third-party includes, which have nothing to do with Qt.
Qt's includes.
My own project's includes.

In my experience this hopefully leads to the least interference between them.