Problem with new Visual Studio update 2017 Version 15.8.0 and Qt 5.9.5
-
Easiest solution is to just not use Visual Studio. It's an unnecessarily bulky framework that, if I'm not mistaken, runs wayyy slower than Qt.
At the very least, re-consider WHY you want to use Visual Studio. If it's for specific APIs or libraries, there's a good chance they're probably available for Qt, as well. (open source is a wonderful thing)
-
Hi and welcome to devnet,
Please take a look at this thread about VS 15.8 on the development mailing list.
-
Hello Qt community,
@kkoehne My configuration is:
Microsoft (R) C/C++ Optimizing Compiler Version 19.15.26726 for x86
@devDawg You are absolute right. But this is a company decision - I have to use Visual Studio.
@SGaist thank you very much. In the mailing list is recommended to delte ".qmake.stash" files. I don't find any ".qmake.stash files" on my hard disk. I use Microsoft Visual Studio 2007 only and do not use qmake. I use the Visual Studio Plugin "Qt VS Tools" to generate the Visual Studio Project for Qt.
Today I generated a complete new fresh Project (Qt GUI Application with "Qt VS Tools"), and I have the same errors as with my main project yesterday. So my problem is not solved.Thanks to all!
Many greetings from Germany,
Matthias -
Hello Qt community,
sorry, I have missed an entry in the mailing list.
This is a known with Qt and VS problem.quote from mailing list:
"Another issue: 5.9 doesn't build in 32-bit x86. Fix is in
https://codereview.qt-project.org/236948 (backport of
c59cb9809559f0aae6be8544cb2049e41f8040e9)."Thanks to all!
Many greetings from Germany,
Matthias -
Hello Qt community,
Success! With the new "qalgorithms.h" the x86 build works great again.
For your information:
[https://codereview.qt-project.org/#/c/236948/2/src/corelib/tools/qalgorithms.h](link url)Special thanks to @SGaist !
Problem solved!
Many greetings from Germany,
Matthias -
@Taytoo said in Problem with new Visual Studio update 2017 Version 15.8.0 and Qt 5.9.5:
Is the fix same?
If you use 15.8 then yes - it makes no different if you build Qt static or not here.
-
@Christian-Ehrlicher I have Visual Studio 2017 15.9.6 and Qt 5.12.0. Just tried the fix and its Not working.
-
@Taytoo said in Problem with new Visual Studio update 2017 Version 15.8.0 and Qt 5.9.5:
Just tried the fix and its Not working.
Which fix?
-
@Doctor-G said in Problem with new Visual Studio update 2017 Version 15.8.0 and Qt 5.9.5:
I replace the qalgorithms.h cleaned the cmake cache, did a full rebuild. And now it is working for me also.
I am using VS2017 15.9.4 and doing a x64 build with release symbols.
@Christian-Ehrlicher said in Problem with new Visual Studio update 2017 Version 15.8.0 and Qt 5.9.5:
@Taytoo said in Problem with new Visual Studio update 2017 Version 15.8.0 and Qt 5.9.5:
Just tried the fix and its Not working.
Which fix?
The one above
-
Then I would say - update to 5.9.7 and make sure no old Qt version is around and try again since it's fixed in 5.9.7
-
@Christian-Ehrlicher you mean downgrade Qt from 5.12.0 to 5.9.7 - that's quite an old version. I need the high-dpi support in Qt.
Can anyone look into this issue, I'm sure I'm not the only one on 5.12.0 branch using VS2017?
-
You're using 5.12? Then the fix is in there already... the problem here was only due to problems with Qt5.9.5/.6 and VS 2017...
Do you compile Qt on your own? -
@Christian-Ehrlicher said in Problem with new Visual Studio update 2017 Version 15.8.0 and Qt 5.9.5:
You're using 5.12? Then the fix is in there already... the problem here was only due to problems with Qt5.9.5/.6 and VS 2017...
Do you compile Qt on your own?Yes and Yes
-
Fixed preprocessor error by updating header file:
#if defined(__cplusplus) #if defined(__clang__) #if QT_HAS_CPP_ATTRIBUTE(clang::fallthrough) # define Q_FALLTHROUGH() [[clang::fallthrough]] #endif #elif defined(__GNUC__) #if QT_HAS_CPP_ATTRIBUTE(gnu::fallthrough) # define Q_FALLTHROUGH() [[gnu::fallthrough]] #endif #elif QT_HAS_CPP_ATTRIBUTE(fallthrough) # define Q_FALLTHROUGH() [[fallthrough]] #endif #endif
-
@aha_1980 The change was in qcompilerdetection.h Line: 1349.
Weird thing is that now that I've fixed the linker issue I was experiencing, compiler is Not complaining of the code - I've reverted qcompilerdetection.h back to its original version. Even though, looking at the file in VS the offending lines are still marked red, I guess moc is taking care of it somehow.