[Development] Shall we turn on /utf-8 compiler option when build qt for Windows?
Start from qt-5.8 I can't build qt anymore under Windows(simplified chinese locale). Since there is a file src/plugins/generic/tuiotouch/qtuiohandler.cpp which contain non-latin-1 character, msvc2015 assume the source code's character set should be CP936 which make the complilation fail. I can only build qt by comment the line which contain the specical character in src/plugins/generic/tuiotouch/qtuiohandler.cpp. But if I turn on -developer-build in configuration step, thing will get worse than before, since -developer-build means treat warning as error, and again I can't build qt anymore since there are other files contain non-latin1 character (such as qstring.cpp), the build will fail due to the character set warning. I am working on a Windows 10 x64 simplifed chinese machine, msvc2015 update3 For more detail please refer to https://bugreports.qt.io/browse/QTBUG-58161 As a workaround, I have to modify the file qtbase/mkspecs/common/msvc-desktop.conf QMAKE_CFLAGS= -nologo -Zc:wchar_t /utf-8 After I add /utf-8 compiler option the build goes well. Shall we turn on this compiler option by default? ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Incorrect TLS Session Verification on macOS with OrLater Options
On Sat, Jan 28, 2017 at 12:16 AM, Jason A. Donenfeld wrote:
> Hi,
>
> The file src/network/ssl/qsslsocket_mac.cpp contains a nasty bug
> preventing the use of setProtocol(QSsl::TlsV1_2OrLater):
>
> bool QSslSocketBackendPrivate::verifySessionProtocol() const
> {
>bool protocolOk = false;
>if (configuration.protocol == QSsl::AnyProtocol)
>protocolOk = true;
>else if (configuration.protocol == QSsl::TlsV1SslV3)
>protocolOk = (sessionProtocol() >= QSsl::SslV3);
>else if (configuration.protocol == QSsl::SecureProtocols)
>protocolOk = (sessionProtocol() >= QSsl::TlsV1_0);
>else
>protocolOk = (sessionProtocol() == configuration.protocol);
>
>return protocolOk;
> }
>
> In the else clause, it checks for equality between sessionProtocol()
> and the configuration protocol. If the configuration protocol is
> *OrLater, this will always be false, and so verification will never
> succeed. And indeed, sessionProtocol() never returns an OrLater
> response:
>
> switch (protocol) {
>case kSSLProtocol2:
>return QSsl::SslV2;
>case kSSLProtocol3:
>return QSsl::SslV3;
>case kTLSProtocol1:
>return QSsl::TlsV1_0;
>case kTLSProtocol11:
>return QSsl::TlsV1_1;
>case kTLSProtocol12:
>return QSsl::TlsV1_2;
>default:
>return QSsl::UnknownProtocol;
>}
>
> The solution is to properly match the OrLaters and use the usual >=
> comparison.
>
> A current workaround is to hard code the SSL version and not use an
> OrLater, which is a bummer. Please fix and backport to LTS.
>
> Thanks,
> Jason
> ___
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
Hi Jason,
Thanks for reporting this.
I'm working on fixing it here (currently WIP):
https://codereview.qt-project.org/#/c/183781/
Thanks,
Mikkel
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Policy for examples with large resources?
On Friday 27 January 2017 15:48:54 Sean Harmer wrote: > Obviously putting these directly in the qt3d repo is not ideal yet we need > examples to demonstrate this stuff (and more in the future). Is there a way > we can get a git-lfs repo set up as a submodule to be referenced by the > qt3d repo? > > Or is there some other solution that would be preferred? I wholeheartedly recommend that you diverge as little as possible from Git LFS. The experience on the client side is really good, and with git v2.11 (easy to compile locally if your vendor doesn't ship it) the speed has been increased 70 times with a new filter system, so it is close to the speed that native support would give you. The problem for the Qt project is server side. Github, Gitlab and Bitbucket have support for LFS, but there is no production ready open source standalone LFS server (https://github.com/git-lfs/git-lfs/wiki/Implementations) that could live side by side with gerrit. Using those 3rd parties would be an option, but I don't see how, given that contribution to gerrit is different than the pull-request model of those. The LFS blobs are uploaded as a pre-push hook, so that could be replaced by a script that runs rsync to upload your .git/lfs/objects that are not yet on the server. That way you ensure all versions are kept. Then, the download of files happens in the "smudge" filter. You could replace that by a script that checks if the blob is there, downloads it, then calls git-lfs-smudge. I think you bypass all Git LFS usage of the network, but then your history would still be compatible, and the workflow good. Oh, and there is also a custom transfer support, but I haven't tried myself: https://github.com/git-lfs/git-lfs/blob/master/docs/custom-transfers.md -- Viking Software, Qt and C++ developers for hire http://www.vikingsoft.eu ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
