Using 32 bits library on 64 bits platforms
Another problem about the cross compilation on Linux (Debian Squeeze).
This time, I have compiled all my application (plugins included) with the correct options (-m32 and some other compiler flags to force 32 bits compilation on 64 bits platforms).
So, when I perform a :
I get something like that : 32 bits LSB executable
For each of my plugins, I also have the same architecture output :
When I check the ldd command, either on the application or on the plugins, all of them are linked to the 32 bits versions of Qt libraries.
Nevertheless, when I try to load one plugin after having lauched the application, I got this problem
expected build key "i386 Linux g++-4.* full-config", got "x86_64 Linux g++-4.* full-config"
I didn't manage to find it out !
Could someone help me ?
Thanks a lot !
Did someone solve this issue ? I didn't :(
Well.. did you pass the appropriate makespec to configure? And, thats unusual, I have for some time now, compiled Qt regularly without problem in 32bit on 64bit machine.. mostly on Windows, didn't try this particular combo under Linux, but I might in a day or two. Will update you then.
Seems that it tries to load the plugins from the wrong path. Did you check the library paths with something like this:
qDebug() << QApplication::libraryPaths();
Thanks. I try it today and I keep you aware of the results.
I forgot to precise that I'm using CMake to compile my project.
But I suppose there exists a command to set the makespec in the cmake tool.
I'll try to find it that day !
hmm okay... i was talking about the Qt install. I'm guessing, it should be okay to use CMake for your project, don't think the makespec affects this. Just to confirm.. you're trying to create Qt Designer plugins right? I'll post the settings we use, translated to linux, once I get to work.
The plugins are not Qt designer plugins, just plugins inheriting from an interface, and with a source file declaring the macro Q_EXPORT_PLUGIN2.
It try to load them using the QPluginLoader. It's during this operation that I have this error.
Thanks for your reactivity, I'm also on it ;-)
As you are on Linux, there is a relatively easy way to check what's going on:
strace -e trace=file -o file-open-log.txt /path/to/your/application
This leaves a file file-open-log.txt in your current directory. In that, all file system calls are logged (including stat for checking if a file exists). You can check which plugins and libraries are actually pulled into your application.
I solved some otherwise mysterious plugin path errors this way.
Breaking news : I manage to load the plugin using the QLibrary object. However, I still have the problem when I use the QPluginLoader object. The only difference between those two objects seems to be :
QPluginLoader checks the plugin is linked against the same libraries as the main application, QLibrary doesn't.
Do someone know how can I modify the built key using cmake ?
Guys ? No one can help me ?
I tried to change the qmakespec, to came back to Qmake compilation (not using the cmake tool).
And I still got the same issue. It seems Qt doesn't recognize the plugins have been built using a cross compilation 32 bits on a 64 bits architecture.
Could it be a bug of Qt itself ?
I doubt it's a bug of Qt.
I would guess for a wrong path to an include file. The build key is defined in QtCore/qconfig.h, it has a #define QT_BUILD_KEY in it. Maybe you pick up the default from your 64 bit system, instead of the adapted for the 32 bit cross compiler?
On Qt Debian squeeze, do I have to install some specific 32 bits headers ?
Or more generally, how can I pick up the correct build key ?
Thanks a lot for your help !
The standard installation would be a 64bit, I guess. If you have built Qt 32 manually it should be in /usr/local/Trolltech/Qt-4.7.x if you used the default path and did a make install. You must make sure that you use the qmake of that path to build your plugin. Also, make sure that none of the system provided include files are used. You can check the command lines of your compiler calls, it must not contain paths to e.g. /usr/include/qt4, as this would be the wrong version.
Yes, I got it. Thanks.
The matter is I didn't compile Qt manually. And I don't want to. I have to install it from the Debian packages.
So, my question was more : on the specified platform, do those 32 bits headers exist in the Debian default packages ? I already run an apt-cache search and I didn't find some obvious file. Do you ?
(excuse my poor English, it's not my native language)
If there is no separate package, I would say: no.
But that's getting kind of out of scope for this forum now. To get a definitive answer I would better ask in a Debian forum. I personally have only an older version of Kubuntu running.