[Development] Focusing bug fixes to 5.9 branch and patch releases during H1/17

Gunnar Roth gunnar.roth at gmx.de
Mon Feb 13 14:13:59 CET 2017


 
 


>> vcblog says: " Specifically, VS 2015 and VS “15” will have the same major>
>> compiler version (19) and their STLs will be binary-compatible, and this
>> compatible compiler and STL will remain available throughout the lifecycle
>> of VS “15”. This implies that the STL’s DLL will continue to be named
>> msvcp140.dll. (At some point in the future, we expect to have a compiler
>> version 20 and a binary-incompatible STL again.)"
>
>This needs to be tested. It's not only binary compatibility, it's also the way
>that Windows does DLLs -- especially the VC runtime ones. It's possible to
>load more than one with different manifest information, which by itself is
>problematic. But then you can't delete in one pointers new'ed by another,
>which is a much bigger problem.
>Maybe that's fixed. Maybe it isn't. Someone who knows more about DLLs,
>manifests, and VC needs to check this
well as the vcruntime is still called 140, a vs2017 runtime will supersede your 2015 runtime,
if your manifest says use the latest. So there is no difference between the different vs2015 update versions. Ms needs to keep them compatible, especially the allocator.


>> yes dropping vs2015 build as using the latest 19.xx compiler will be binary
>> compatible to vs2015 code.

>We can't drop it from the CI. I don't think we can drop it from the build
>packages either, since usually you compile with the oldest you plan to use. So
>if you're correct and VS2017 is binary-compatible, then we are already
>providing the packages for VS2017.

Yes but then you do not have the many performancee optmisations ( better constexpr, better vector preformance, compiler optimisations) in the qt build.

>> > But we did make MSVC 2017 work with 5.8. We solved all build issues we
>> > could find.
>>
>> Well sadly that does not include 5.8.0, so now users have to wait at least
>> until may to get a vs2017 ( which will be released on March 9th).
>
>We had planned on having 5.8.1 before that release. Unfortunately, it's not
>going to happen, due to lack of resources. 5.8.1 is postponed indefinitely and
>will most likely not happen.

Actually I expected that, because that's Murphy's Law ;-)

But as I always build Qt myself to be able to add patches and to have release pdbs, I myself do not care so much,
I just think it would give Qt a better look for other users, to support 2017rc.


>The win32-msvcXXXX mkspecs have been dropped as of Qt 5.8.0. They're all now
>called "win32-msvc" and the actual versions are extracted from the compiler
>itself, to enable command-line options as needed. The plan was for 2017 to not
>get an mkspec of its own, but we had to add it for compatibility with Qt
>5.6.3, which apparently needed to get one of its own.

Hmm what do you mean? If i do a dir win32* in the mkspec folder of qtbase of Qt 5.8.0, I get this:
24.01.2017  17:37    <DIR>          win32-clang-msvc2015
24.01.2017  17:37    <DIR>          win32-g++
24.01.2017  17:37    <DIR>          win32-icc
24.01.2017  17:37    <DIR>          win32-msvc2005
24.01.2017  17:37    <DIR>          win32-msvc2008
24.01.2017  17:37    <DIR>          win32-msvc2010
24.01.2017  17:37    <DIR>          win32-msvc2012
24.01.2017  17:37    <DIR>          win32-msvc2013
24.01.2017  17:37    <DIR>          win32-msvc2015
24.01.2017  17:37    <DIR>          win32-msvc2017

So there is lot of unsupported msvc versions (2005,2008,2010,2012), but no win32-msvc mkspec.

Regards,
Gunnar Roth.



More information about the Development mailing list