Problems encountered when the project moved from Mingw to MSVC 2017
-
@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. -
@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”的多次声明 -
@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? -
@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”的多次声明 -
@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 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? -
@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
- error:D:\QtProjects\autotest\1026msvc\autotestsystem\AutoTestSystem\AcBoard\AcBoardEntity.h:304: error: C1060: 编译器的堆空间不足
-
@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.
-
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
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 likeclog
for it to cause an error when included. -
@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#include
d somewhere, and that may be preceded by other#include
s and/orusing namespace
statements, etc. You cannot keep looking atcomplex.h
in isolation, you must look at it in the context of where it is being included. -
@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
You were not supposed to be able to findclog
in your own code --- it's incomplex.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 haveusing namespace std
. That will have madeclog
(without the::
) go wrong whencomplex.h
got included. Nowcomplex.h
will be included before thatstd
statement, and will allow it to work.As a general guide: this does not always avoid any problems, but I arrange my
#include
s 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.