d_stranz
16th August 2013, 23:58
I am converting a large Qt 4.8.2 / Visual Studio 2008 project over to Qt 5.1.0 / VS 2012, and at the same time converting Win32 projects over to x64.
I now have all of the code compiling without errors. However, when I get to the link step in a 64-bit (x64) project, I end up with undefined symbols QString::fromStdWString() and QString::toStdWString().
This is almost always related to a mismatch between settings for the code generation property "Treat WChar_t As Built in Type", which can either be set to "Yes (/Zc:wchar_t)" or "No (/Zc:wchar_t-)". Throughout all of recorded history, I have always set this flag to "No". When I use the Qt5 plugin for Visual Studio to create a new Qt project, the plugin sets it to "No". However, even with a bare-bones plugin-created project:
#include <QtCore/QCoreApplication>
#include <QString>
#include <string>
int main(int argc, char *argv[])
{
QCoreApplication a(argc, argv);
QString foo = QString::fromStdWString( L"bar" );
std::wstring bar = QString( "foo" ).toStdWString();
return a.exec();
}
I get a link error, unless I set the wchar_t flag to Yes (treat it as a built-in type).
I installed Qt 5.1.0 by downloading the "Qt 5.1.0 for Windows 64-bit (VS 2012, OpenGL, 522 MB)" offline exe installer from the qt-project.org downloads page.
Has the treatment of wchar_t changed in Qt 5?
******* Edit ************
I'll answer my own question: Yes.
In the mkspecs qmake.conf file in win32_msvc2008 for Qt 4.8.2, there's this line:
QMAKE_CFLAGS = -nologo -Zm200 -Zc:wchar_t-
In the same file for Qt 5.1.0, the line now reads (and it is the same in all of the qmake.conf files for the different msvc versions):
QMAKE_CFLAGS = -nologo -Zm200 -Zc:wchar_t
The flag has been flipped! Why?
Unless we edit the project files and rebuild every library and executable used in the entire company, we're going to be forced to build Qt from sources after editing the config file, and remember to do it with each new update.
I now have all of the code compiling without errors. However, when I get to the link step in a 64-bit (x64) project, I end up with undefined symbols QString::fromStdWString() and QString::toStdWString().
This is almost always related to a mismatch between settings for the code generation property "Treat WChar_t As Built in Type", which can either be set to "Yes (/Zc:wchar_t)" or "No (/Zc:wchar_t-)". Throughout all of recorded history, I have always set this flag to "No". When I use the Qt5 plugin for Visual Studio to create a new Qt project, the plugin sets it to "No". However, even with a bare-bones plugin-created project:
#include <QtCore/QCoreApplication>
#include <QString>
#include <string>
int main(int argc, char *argv[])
{
QCoreApplication a(argc, argv);
QString foo = QString::fromStdWString( L"bar" );
std::wstring bar = QString( "foo" ).toStdWString();
return a.exec();
}
I get a link error, unless I set the wchar_t flag to Yes (treat it as a built-in type).
I installed Qt 5.1.0 by downloading the "Qt 5.1.0 for Windows 64-bit (VS 2012, OpenGL, 522 MB)" offline exe installer from the qt-project.org downloads page.
Has the treatment of wchar_t changed in Qt 5?
******* Edit ************
I'll answer my own question: Yes.
In the mkspecs qmake.conf file in win32_msvc2008 for Qt 4.8.2, there's this line:
QMAKE_CFLAGS = -nologo -Zm200 -Zc:wchar_t-
In the same file for Qt 5.1.0, the line now reads (and it is the same in all of the qmake.conf files for the different msvc versions):
QMAKE_CFLAGS = -nologo -Zm200 -Zc:wchar_t
The flag has been flipped! Why?
Unless we edit the project files and rebuild every library and executable used in the entire company, we're going to be forced to build Qt from sources after editing the config file, and remember to do it with each new update.