No Solution? Cannot mix incompatible Qt library
-
Hi TRexial.
the problem is in you qtcreater settings. On my notebook I have 5 different Qt version installed and every of them are working.
It is important that you set correctly the settings int the qtcreator Tools->Options->Build&Run
You have to set "Kits" and "Qt-Version" correctly.In case of a dummy project this should only depends on Qt but it seems to me that you are trying to link against KDE as well.
Neither should you blame qt nor anything else. I think you should blame your self.
Cheers
-
Well if it is me, I'm not exactly sure what I'm missing then. Here is what is lists under the "Kits" tab...
Name: Desktop
Device Type: Desktop
Device: Run locally (default or Desktop)
Sysroot: (BLANK as is nothing is set)
Comipler: GCC (x86 64bit)
Debugger: GDB Engine using "/usr/bin/gdb"
Qt Version: QT 4.8.4 in PATH (QT-4.8.4)
Qt mkspec: (BLANK as is nothing is set)OK, now here is what is set under the "Qt Versions" tab...
Manual
|---> Qt 4.8.4 in PATH (Qt-4.8.4) /usr/local/Trolltech/Qt-4.8.4/bin/qmakeVersion name: Qt 4.8.4 in PATH (Qt-4.8.4)
qmake location: /usr/local/Trolltech/Qt-4.8.4/bin/qmake
Qt version 4.8.4 for Desktop
Helpers: QML Dump.What am I missing? I'm still not blaming myself just yet, maybe soon, but not yet.
-
Qt is actually conflicting with a version shipped with KDE. Sadly, this is not easy to fix. Try removing (or resetting to your Qt 4.8.4) plugin paths from project's Run Environment (you will notice some entries have "kde" in their path).
-
I've tried that, still the error persists.
Looks like qmake can't keep it's head together and look where it is told. Looks like it is picking from /usr/lib when it feels like it, probably something in /usr/lib/kde4.
I downloaded 4.8.3 and sure enough, it works just fine out of the box. No problems whatsoever.
This isn't an uncommon error, however I can't find a single straight answer that works for this.
Anyone have an idea for jailing qmake accordingly?
-
Correct, I've run into this myself numerous times, and - like you - usually reverted to the same version I had on the OS. Searching for an answer did not provide any good solutions. The only way was to keep updating the system to newest releases. Interestingly, this is certainly fixable - Qt Creator does work regardless of Qt version installed (take a look at qtcreator.sh for an insight at how it's done), but not trivial.
On the other hand, IIRC Qt5 did not have this problem (yet).
-
I'm too new to the gnu/linux enviroment to find an entry point in solving this quickly. It seems to me that if someone could limit the enviroment at the time of qmakes execution, it could be solved. Is there a way to point a directory to another for only 1 program? Say, when a process runs have /some/directory/name linked to /a/different/directories/name , but of course only for the run of that process?
I'm just not familiar enough with this enviroment. Neh, I'm too ignorant to it, ignorance is the problem here. I've never encountered this problem on Windows, nor have I ever had the need for this remedy on Windows for any application, so I'm extremely ignorant in all regards.
I'm sure there is a way to get it working that can be done in a matter of seconds with just a page full of shell commands (or at least that is what my logic is telling me to think). I'm reading up on jailing processes currently, but there seems to be many more methods than I thought. I've also thought about creating a user group essentially just for the qmake process. From where I'm sitting though, it looks to be that walling off the qmake process is what needs to be done.
-
LD_LIBRARY_PATH env. variable can be used to force a change in library search paths. That is what Qt Creator uses, in fact. But this not the whole story and I remember it did not help me in fixing this particular problem.
-
What exactly did you do when you get that error message? Did you get it while setting up the dummy project, while building it or when running it?
Creator only takes the output of "qmake -query" for information on where things are installed into account and then goes off to look at the QtCore library to figure out what the Qt version is targeting.
So can you actually run "qmake -query" in the same environment you start Qt Creator in?
-
I get the error message after runing the compiled program. I'm doing everything from the shell now, I've left QtCreator behind for the time being. However, I get the same error message in qtcreator.
I'm following this page... http://doc.qt.digia.com/4.3/tutorial-t1.html I'm doing this exactly...
qmake -project
qmake
make
./myProgramIt is when I run myProgram the error occurs. Compilation is fine. I have ran strace on both qmake and ./myProgram in the steps above. I'm not familiar with strace, but I can say a lot of kde4 directories are accessed. I know this might not mean anything, but running qmake with strace shows plenty of activity is going on with the correct lib, then it starts using the kde4 libs, then it starts back using the correct libs again. If this foreshadows anything, strace -c ./myProgram shows 350 calls to "open", which 119 are errors. 151 calls to "access", which 80 are errors. Dunno.
After deciding that I need to be more intimate with strace, which I'm currently not, I then took to this page...
http://doc.qt.digia.com/qt/qmake-variable-reference.html
I used a logical approach to shooting in the dark with the references and added a few things to the ".pro" file...
DEPENDPATH
QMAKE_LFLAGS_PLUGIN
QMAKE_LFLAGS_RPATHAfter assigning those to various directories within the ".pro" file (again, shooting in the dark), the program would return 1 error or compile fine. A variable I haven't tried extensively is QMAKESPEC, which I'm not sure how to set accordingly, or if I even need to.
Nothing in the Makefile or ".pro" file points to kde4, everything looks correct with those 2 files.
I have also tried setting the $QT_LIBRARY_PLUGINS to an empty string, however, even empty the error still occurs. I have also set the $LD_LIBRARY_PATH as well, same error. On my system this variable was not set. What I read is that if I'm using gcc then it might not be, and I am using gcc so this is why I believe I had to set it.
Where I'm at now is trying to setup a chroot jail on qmake itself. Any input on that at all is welcomed being I think I can get it to work, however I don't understand exactly how it works. Again, I'm reading about it, trying it, but still currently shooting in the dark.
Running "qmake -query" shows...
QT_INSTALL_PREFIX:/usr/local/Trolltech/Qt-4.8.4
QT_INSTALL_DATA:/usr/local/Trolltech/Qt-4.8.4
QT_INSTALL_DOCS:/usr/local/Trolltech/Qt-4.8.4/doc
QT_INSTALL_HEADERS:/usr/local/Trolltech/Qt-4.8.4/include
QT_INSTALL_LIBS:/usr/local/Trolltech/Qt-4.8.4/lib
QT_INSTALL_BINS:/usr/local/Trolltech/Qt-4.8.4/bin
QT_INSTALL_PLUGINS:/usr/local/Trolltech/Qt-4.8.4/plugins
QT_INSTALL_IMPORTS:/usr/local/Trolltech/Qt-4.8.4/imports
QT_INSTALL_TRANSLATIONS:/usr/local/Trolltech/Qt-4.8.4/translations
QT_INSTALL_CONFIGURATION:/etc/xdg
QT_INSTALL_EXAMPLES:/usr/local/Trolltech/Qt-4.8.4/examples
QT_INSTALL_DEMOS:/usr/local/Trolltech/Qt-4.8.4/demos
QMAKE_MKSPECS:/usr/local/Trolltech/Qt-4.8.4/mkspecs
QMAKE_VERSION:2.01a
QT_VERSION:4.8.4Within /etc/xdg/Trolltech.conf it reads...
[qt]
4.8\libraryPath=/usr/lib/kde4/pluginsNot sure if I should change that though.
-
I never found a solution to this. I let it alone and went on to something else. Now I'm back in the arena with the same problem. Researching on the problem to the best of my knowledge gives me the answer of upgrading KDE. That is sloppy and I'm sure it is not needed, however, I still can't understand where and when QT decided to use my systems KDE version instead of the one it is supposed to use.
It's frustrating, but fixable. If anyone has a clue, please let me know.
-
Did you find a solution for this?
I have been struggling with a similar problem on (K)Ubuntu 12.04 where Qt 4.8.1 is installed by default. I built my own version of Qt 4.8.4, but could not start any of the Qt binaries like designer or assistant. Adding LD_LIBRARY_PATH and QTDIR/bin to path did not help.
One thing I discovered was that by running the applications with the option -style cleanlooks it would work. So I suspect the problem comes from the KDE style being loaded from the distro standard version of Qt.
-
I found solution for me.
When you build your own libraries just make sure you compile QtDBus module. Default style for KDE (oxygen) is using that and when it cannot find your library (4.8.4), then tries to load system libQtDBus.so.4 (4.8.1). This causes error with incompatible Qt library version.
