Is wchar_t now a built-in type in Qt 5.1.0 / VS 2012?

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:

Code:

---

#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:

Code:

---

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):

Code:

---

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.

What a royal pain this is turning out to be. In order to build Qt5 on Windows with the "wchar_t as a built-in type" turned off, you have to:

1 - Download the Qt source distribution
2 - Download and install ActivePerl
3 - Download and install Python 2.7
4 - Unzip / untar the Qt distribution (takes about 15 - 20 minutes on a fast PC)
5 - Edit the qmake.conf file in qtbase\mkspecs\win32-msvcxxxx (where 'xxxx' is the MSVC version you use) to change '/Zc:wchar_t' to '/Zc:wchar_t-'
6 - Make sure your Path environment variable includes the paths to the perl and python executables. If not, the build will fail.
7 - Open a Visual Studio command prompt window and go to the top level of the Qt5 source tree
8 - Run configure. I used the following command line for my configuration:

Code:

---

configure -prefix .\qtbase -platform win32-msvc2012 -opensource -opengl desktop -developer-build -mp

---

9 - Run nmake

Code:

---

nmake

---

10 - Go away and come back in 3 or 4 hours. Go see a movie. Have lunch with a friend.

If for some reason something went wrong, fix whatever it was, and then either:

Code:

---

nmake clean
nmake

---

to simply clean and rebuild using the current configuration, or

Code:

---

nmake clean
cd qtbase
nmake confclean
cd ..
configure [...]  (with the arguments you really meant to use the first time)
nmake

---

Then go see another movie or have dinner with your friend.

And then you can start figuring out why you can't rebuild your Qt apps using the version of Qt you just built.

All because someone on the Qt team decided that flipping a bit wouldn't affect anything. I mean, weren't there enough changes between Qt4 and Qt5 without forcing us to recompile everything we use in our apps, whether Qt-based or not? We already changed things to use /Zc:wchar_t- in the first place when we made the switch from MFC to Qt and have a whole suite of libraries and applications built that way. Now, we're expected to change it all back again to the VC++ default just because someone on the Qt team had a bright idea. :mad:

I still can't build the docs, because for some other reason the build assumes that qdoc.exe is living in qtbase\bin\qtbase\qtbase\bin or some other ridiculous place, even though the Qt build built it and put it in qtbase\bin along with all the other Qt executables. Haven't found the magic place where that configuration variable is hidden (yet).

Quote:

---

Originally Posted by d_stranz

10 - Go away and come back in 3 or 4 hours. Go see a movie. Have lunch with a friend.

---

Or use jom instead of nmake and have the time divided by the number of processing threads your machine has (e.g. 4, 6 or even 8).

Tried that, gave up after 4 or 5 attempts to get it working. The build couldn't find jom.exe, even though I made copies every place I thought it might be looking. In hindsight, I should have just copied it somewhere in my Path.

Quote:

---

Originally Posted by d_stranz

In hindsight, I should have just copied it somewhere in my Path.

---

Indeed... :)