Unable to use std::string to/from QString conversion on Windows CE
-
wrote on 22 Mar 2012, 10:12 last edited by
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? -
wrote on 22 Mar 2012, 11:22 last edited by
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.
-
wrote on 22 Mar 2012, 11:43 last edited by
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. -
wrote on 22 Mar 2012, 13:20 last edited by
Do you have std::string support for programs without Qt?
-
wrote on 22 Mar 2012, 14:06 last edited by
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()).
-
wrote on 22 Mar 2012, 14:28 last edited by
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.
-
wrote on 25 Mar 2012, 11:03 last edited by
"@"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.
-
wrote on 2 Apr 2012, 12:29 last edited by
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?
-
wrote on 2 Apr 2012, 12:59 last edited by
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? -
wrote on 2 Apr 2012, 14:20 last edited by
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.
-
wrote on 2 Apr 2012, 14:30 last edited by
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. :(
-
wrote on 2 Apr 2012, 15:10 last edited by
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. -
wrote on 4 Apr 2012, 06:29 last edited by
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.
-
wrote on 4 Apr 2012, 08:42 last edited by
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.
-
wrote on 4 Apr 2012, 08:54 last edited by
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?