Unable to use std::string to/from QString conversion on Windows CE
-
Trying to build Qt 4.7.4 on Windows CE with STL support by using the -stl configure option and making sure I have not defined QT_NO_STL in my qconfig file. Still, I am unable to use the QString::toStdString() and QString::fromStdString() functions.
The error I get is a link error, so it seems they are included in the header files, but not built into the libraries.
Has anyone else had this problem and/or can think of a way to solve it? -
Which IDE are you using?
I have used msvc 2005 and compiled for wince 5. I had to add only the -stl switch and all worked like a charm.
-
Also using MSVC 2005. Nice to know it should be possible to make it work at least... :)
My guess is that there is something in our config that makes it define QT_NO_STL even though we don't do it explicitly. Alternatively, Qt has some kind of problem finding STL, because of some weirdness in our Windows CE SDK. -
Do you have std::string support for programs without Qt?
-
Yes, it's just the conversion functions that don't work. I have to use .c_str() instead, to convert from a std::string, which seems to work, but may cause problems. Converting to a std::string is even more awkward (e.g. toLatin1().data()).
-
As I wrote I had never an issue besides forgetting in the first configure. However, I did only the compilation up to Qt 4.7.2
You are cross-compiling for wince5 or for some other version?I am using .c_str() frequently, because it seems to be easier for me. The other way around looks really ackward.
-
"@"ludde Yesterday evening I started to build the opensource version 4.7.4 for wince 5. Since I am testing an application on wince I thought I could check easily, if I have the same problem as you.
Well, thought was wrong. I have problems to get through the compilation of Qt itself.
@
Creating library ....\lib\QtGuid4.lib and object ....\lib\QtGuid4.exp pngwrite.obj : error LNK2019: unresolved external symbol gmtime referenced in function png_convert_from_time_t ....\lib\QtGuid4.dll : fatal error LNK1120: 1 unresolved externals
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 8\VC\ce\bin\x86_arm\link.EXE"' : return code '0x460'
@I have configured the version as I had before the previous versions. Either some of the libs have changed on my machine, which I do not anticipate or something in Qt setup is different. For me it is not issue, since I can life with the previous versions.
-
I think you can get around this by removing the definition of PNG_CONVERT_tIME_SUPPORTED for Windows CE in src/3rdparty/libpng/pnglibconf.h. (We've done that, although I don't remember exactly why...)
I've tried again to build with STL support, but still get link errors for toStdString and fromStdString. Compilation is fine, so QT_NO_STL is definitely not defined. Wonder if it can have something to do with our use of stlport?
-
OK. Looked into this some more, and am even more confused now...
The unresolved functions are both inlined in the qstring.h file.
How is it even possible to get an unresolved symbol linker error for an inlined function? -
I have commented out the define you suggested and the compilation does. Well, it is still ... . Needs a bit of time.
Just as a question are you changed something of the optimization setting for inline?
Configuration Properties->C/C++->Optimization->Inline Function ExpansionThis is default in my compilations. And I will test it with 4.7.4 as soon as it is finished.
-
I think I found the problem now. We are using stlport, but we have not built Qt against stlport. So there is some mismatch in the signatures for these functions.
Problem is, when I try to build Qt against stlport, it fails because stlport does not define uncaught_exception. So I'm not really sure how to solve it, even though I know what the problem is. :(
-
Is there a particular reason to use stlport?
I am using stl as well and since I did not install anything for supporting stl, it must be what comes with msvc 2005 or possibly standard sdk. -
I'm not sure of the exact reasons, they were using stlport here before I started. But I think in general stlport is considered a more efficient, reliable and compliant implementation of stl compared to the Microsoft implementation. At least I think it has been so in the past - it might have changed.
-
As already posted I am using the ms stl implementation and had never an issue on win ce. The same application is also compiled on linux.
I have successfully compiled the qt 4.7.4 after removing the define as you have recommended. However, I ran into the next problem when trying to add the version to my msvc installation. It did not add it. After several trials I have given up. At the moment I cannot verify that the QString conversation would work on my machine.
-
Well, for us I think changing the stl implementation we use on the device is a bigger task than making Qt work with stlport. But if we cannot make it work with stlport, I guess we might consider that.
Regarding adding Qt 4.7.4 to msvc - you mean adding it to the Qt add-in? I think you have to start Visual Studio as administrator to be able to do that. Maybe that's the problem?