I've installed Qt 4.7(32bits) on 32bits Xubuntu. But, in tool chain it list :
GCC(x86 64 bits) and GCC(x86 32 bits).
When I compile my program, it was compiled with GCC(x86 64 bits).
How do I remove GCC(x86 64bits) from tool chain?
Thanks and Regards.
In Tool Chain(Auto-detected)
GCC x86 64 bits
GCC x86 32 bits
How do I remove GCC x86 64 bits from tool chain?
Thanks and Regards.
You don't need to. The correct tool chain is detected from the build of the Qt variant you use.
I've installed three Xubuntu -10.4,x86 and 64bits on my HP notebook. I put Qt_SDK_Lin32 on the first two OS and Qt_SDK_Lin64 on the last OS. I also have Qt_SDK on a Vista notebook. I wrote client/server program and some data-struct's are exchanged between the client and server. The programs work great between Xubuntu 10.4 and Vista.
This is the reason why I want to compile 32 bits program on Xubuntu-x86. On top of this, there is one struct that doesn't work for g++64.
Hmmm... why don't you fix your code to work on 64bit?
The tool chains listed in Tools->Options->Build & Run->Tool chains are the tool chains available on your system. It does not define which tool chain is used.
When building a project one of the available tool chains is used (Check Projects->Build Settings). Creator will pick the one that will work with the Qt version used by default and won't let you select a incompatible one. So if Creator insists on using a 64bit tool chain then you most likely are working with a 64bit Qt. You can not build 32bit code and expect the application to work with that Qt version.
Please either fix your code to work properly on 64bit systems (it is not that hard!) or install 32bit versions of Qt and all the libraries Qt depends on. Then you can build against that 32bit Qt, using a 32bit GCC.
I did install the same 32 bits version of QT on Xubuntu 11.10 x86 and Xubuntu 10.4 32 bits. I also install g++ using sudo apt-get install g++ on both OS before installing Qt SDK.
I also employ about 20 data structs in the program, Here is the scenario :
One app is ran as server on Vista and the same app is ran as client on Xubuntu using Qtcpip. The server
send some data struct to the client and the client use that block of memory and cast it to approriate
struct. This is the reason I want to build 32 bits application on Vista and Xubuntu.
I should have given up struct types, but they were just too convenient.
Structs can be tricky: C types guarantee that e.g. int is at least 32bit. This can be dangerous when using different OSes/CPU architectures/compilers whenever one of which decides to use 64bit to represent an int. Use quint32 etc. instead. You also need to be aware of padding that is inserted between the fields of your struct.
Then you need to make sure to use a defined byte order when sending numbers across the network. Otherwise certain combinations of hardware will fail to communicate.
Plus you need to make sure text uses a defined encoding when transfering strings and that the actual data is send, not just the memory area used to hold the management information on the string (which is what ends up in a struct).
So while there is nothing stopping you from using structs, you usually do need to do explicit serialization/deserialization steps when sending data across the wire.
You are right about using struct. I might add about 40 to 50 more fuction for serialization/deserialization
instead of just casting to extract correct data into the coresponding struct. I did serialize data before
sending over the wire, Casting data from different OS/CPU are the problem. The best solution for me if
I want data exchange between diffent OS/CPU is to put all those data into a long qstring
then to qbyte before storing it to the disq or sending it over the wire. And do the reverse.
Thanls for respones.
[[Doc:QDataStream]] could be of help in your case. It serializes many well known Qt types as well as some of the standard types of C/C++ in a platform independent manner. It's perfectly suited for transmission over the network.
One more last question. Is QChar having the same bytes arrangement between the BigEndian and LittleEndian machine?
It is a 16bit unsigned int IIRC, so no.