Qt has wchar_t as non-native?

[Wasabi]

In qmake's .conf file for Visual 2008, it has the following line:


QMAKE_CFLAGS = -nologo -Zm200 -Zc:wchar_t-

I've had a few problems using another library and I've been informed this is due to Qt compiling with "treat wchar_t as a built-in type" as false, as evidenced by the code above.

Is there any particular reason for this? I've also been told to alter this .conf file, recompile Qt and it should still work just fine.

[Wasabi]

Could anyone please answer this?

[ChrisW67]

/Zc:wchar_t turns on "wchar_t Is Native Type" according to the docs: http://msdn.microsoft.com/en-us/library/dh8che7s%28VS.71%29.aspx
I cannot see any documentation of the appended hyphen, which I assume negates the option.

Since this affects compilation, and not dynamic linking, I can only assume you incorporated the code of the other library into your own.

Options:

Build the other library separately (using its own Makefiles etc.) and dynamically link to it.
Build the other library separately and statically link to it.
#include <wchar.h> in the library source files to define wchar_t (See MS doc above)
quarantine the other library code in a separate directory within your source and
change QMAKE_CFLAGS in the PRO file that builds that portion.

[Wasabi]

Thing is, I've been using this other library (SFML) for a while now and it works quite fine. It was only when I tried to build a program as a qmake makefile that it gave an error (as opposed to a standard Visual Studio build... whatever one's supposed to call that...). And all the errors were due to "function overloads" involving wchar.

[ChrisW67]

I assume the error message building your program stems from the include files out of SFML. If you:


#include <wchar.h>
#include <SFML/...>

in your source files does that straighten it out?

[Wasabi]

Well, by the time I'd seen your guys' responses, I'd already had Qt recompiling without that "-Zc:wchar_t-" flag. While simply adding #include <wchar.h> would probably have been far easier (not to mention Qt-compliant), everything seems to be working perfectly well. Qt isn't spitting out any warnings or errors, qmake is building everything just fine, SIGNALS and SLOTS are working as per usual, and SFML and is most pleased.

So, for the record, while simply doing the #include should work (I didn't try it myself, but it makes all the sense in the world), recompiling Qt without the flag seems to work as well.

Though I am just a newbie and for all I know qmake is crying in desperation.

[Peacs]

I had the same problem and foudn that just including wchar.h didn't work because all libraries used are compiled with "-Zc:wchar_t-", so you get linker errors. Compiling Qt with the adusted .conf file is the only solution here. There is already an issue submitted on this. See http://bugreports.qt.nokia.com/browse/QTBUG-9617 for more details

[nroberts]

I had the same problem and foudn that just including wchar.h didn't work because all libraries used are compiled with "-Zc:wchar_t-", so you get linker errors. Compiling Qt with the adusted .conf file is the only solution here. There is already an issue submitted on this. See http://bugreports.qt.nokia.com/browse/QTBUG-9617 for more details

Anyone know why in this one: http://bugreports.qt.nokia.com/browse/QTBUG-6345?page=com.atlassian.jira.plugin.system.issueta bpanels:all-tabpanel#issue-tabs they say that building Qt this way won't be supported? The question's been sitting there for a year and nobody's ever answered it! I've been scared to apply this fix to our situation because of that statement but it's really becoming a true PITA.

And WTF do BIC and SIC mean??