Cannot mix incompatible Qt library
-
@jsulm: Yes I did, not sure if I interpret it well:
$ ldd QtDatabaseTest linux-vdso.so.1 => (0x00007ffc005db000) libQt5Network.so.5 => /usr/local/lib/libQt5Network.so.5 (0x00007fe39106f000) libQt5Sql.so.5 => /usr/local/lib/libQt5Sql.so.5 (0x00007fe390e2a000) libQt5Core.so.5 => /usr/local/lib/libQt5Core.so.5 (0x00007fe3906da000) libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fe390358000) libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fe390142000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fe38fd78000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fe38fb5b000) libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fe38f941000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fe38f638000) libicui18n.so.56 => /usr/local/lib/libicui18n.so.56 (0x00007fe38f19f000) libicuuc.so.56 => /usr/local/lib/libicuuc.so.56 (0x00007fe38ede7000) libicudata.so.56 => /usr/local/lib/libicudata.so.56 (0x00007fe38d404000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fe38d200000) libgthread-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgthread-2.0.so.0 (0x00007fe38cffe000) libglib-2.0.so.0 => /lib/x86_64-linux-gnu/libglib-2.0.so.0 (0x00007fe38cced000) /lib64/ld-linux-x86-64.so.2 (0x00007fe391405000) libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007fe38ca7d000) $ ldd /usr/local/lib/libQt5Sql.so.5 linux-vdso.so.1 => (0x00007ffde4db4000) libQt5Core.so.5 => /usr/local/lib/libQt5Core.so.5 (0x00007ff4c47b0000) libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007ff4c4593000) libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007ff4c4211000) libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007ff4c3f08000) libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007ff4c3cf2000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007ff4c3928000) libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007ff4c370e000) libicui18n.so.56 => /usr/local/lib/libicui18n.so.56 (0x00007ff4c3275000) libicuuc.so.56 => /usr/local/lib/libicuuc.so.56 (0x00007ff4c2ebd000) libicudata.so.56 => /usr/local/lib/libicudata.so.56 (0x00007ff4c14da000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007ff4c12d6000) libgthread-2.0.so.0 => /usr/lib/x86_64-linux-gnu/libgthread-2.0.so.0 (0x00007ff4c10d4000) libglib-2.0.so.0 => /lib/x86_64-linux-gnu/libglib-2.0.so.0 (0x00007ff4c0dc3000) /lib64/ld-linux-x86-64.so.2 (0x00007ff4c5145000) libpcre.so.3 => /lib/x86_64-linux-gnu/libpcre.so.3 (0x00007ff4c0b53000)@Maikie130 Looks good
-
Hello!
Recently, I have fiddled around and made some projects for my Linux (ubuntu) server. I would like to keep the installations of the tool(s) as simple/small as possible. So, what I do is create Qt C++ console application(s), upload them with FTP and use the ldd command to check which libraries are missing and fetch those from the Qt designer installation, upload them into /usr/local/lib and use ldconfig. Until now that has been working perfectly fine for me.
I now have a project which should connect to a local database, so I added QT += SQL to my project file. And on my qtCreator VM (Ubuntu desktop) this all seemed to work fine. I uploaded the project to my sever, searched-up the libQt5Sql.so and installed it.
Now when running the application, I was expecting a message about installing the appropriate drivers. But actually I'm getting the following output (after a few qDebug lines...):
- Cannot mix incompatible Qt library (version 0x50701) with this library (version 0x50a01)
Strange thing is that I (believe) everything should be Qt 5.7.1, but it seems like something wants to mix with something of version 5.10.1
What would be the best way to find out which library/application is at fault there? These libraries have been working for other apps, so my guess would be the SQL library... but when I replace it with a complete different one, the first version-value in the message changes ("cannot mix.... version 0x040602.... version 0x50a01").
Thank you for your thoughts!
Maikie@Maikie130 when you say you simply copy the libs from qtcreator do you mean the libs found in Qt/Tools/QtCreator/......
or the ones found in
Qt/5.7.1/compilername/...if the former, than chances are you were copying the wrong files all along.
-
@Maikie130 when you say you simply copy the libs from qtcreator do you mean the libs found in Qt/Tools/QtCreator/......
or the ones found in
Qt/5.7.1/compilername/...if the former, than chances are you were copying the wrong files all along.
-
@J.Hilk I have been copying them from the following folder: '/home/<user>/Qt/5.7/gcc_64' So, I suppose that is the latter.
@Maikie130 ok that at least should be correct ;-)
-
Hi,
Did you also copy the corresponding SQL plugins ?
-
wrote on 16 Apr 2019, 21:46 last edited by
You probably don't want to copy libraries for one Application into /usr/local/lib, since everything on the system can pick up libraries there.
That said, check out: https://github.com/linuxdeploy/linuxdeploy
It's a utility for automagically gathering up Linux library dependencies and setting up their search path so an app can run conveniently out of a self contained directory. There is even a plugin for linuxdeploy to grab secondary Qt dependencies like SQL driver plugins that get loaded at runtime that don't show up with a utility like ldd. -
wrote on 17 Apr 2019, 14:17 last edited by Maikie130
@SGaist Thanks for the thought! I didn't, so fixed that now... Still the same message however :c
@wrosecrans It sounds really good (that said, I actually wanted to install them globally, as I have multiple tools running of the same libs. Is this bad practice?), I have fiddled around with it for some time now, but I can't really seem to be getting it to work. What I did is clone the git repo, fix one million dependencies and ran cmake/make on it. I do have the executable now, but I am unsure about how to use it (also, the qt-plugin doesn't want to compile due to missing dependencies, which are a pain to gather around). I must admit that I am quite new to the whole git/cmake/etc, so sorry for the nuisance.
@jsulm & @J-Hilk thanks for checking!
-
Then install your custom version of Qt in a clearly dedicated folder and use RPATH to ensure your applications are looking in the right folders to get your custom Qt version.
-
Then install your custom version of Qt in a clearly dedicated folder and use RPATH to ensure your applications are looking in the right folders to get your custom Qt version.
wrote on 18 Apr 2019, 08:06 last edited by Maikie130@SGaist Thanks for the tip, I did this and used ldd again to fix teh paths to the new directory. Seems like the Qt core lib was 5.10, which (probably?) wasn't a problem for the other tools, but in combination with the SQL plugin it gave me that error.
-
@SGaist Thanks for the thought! I didn't, so fixed that now... Still the same message however :c
@wrosecrans It sounds really good (that said, I actually wanted to install them globally, as I have multiple tools running of the same libs. Is this bad practice?), I have fiddled around with it for some time now, but I can't really seem to be getting it to work. What I did is clone the git repo, fix one million dependencies and ran cmake/make on it. I do have the executable now, but I am unsure about how to use it (also, the qt-plugin doesn't want to compile due to missing dependencies, which are a pain to gather around). I must admit that I am quite new to the whole git/cmake/etc, so sorry for the nuisance.
@jsulm & @J-Hilk thanks for checking!
wrote on 18 Apr 2019, 23:31 last edited by@Maikie130 If you have many tools, you can toss them all in the bin dir of one big AppDir made by linuxdeploy. For example, /opt/maiki/usr/bin and everything in that bin dir will get set with rpath by linuxdeploy to look for libraries in /opt/maikie/usr/lib, but nothing else on the system will get impacted by those libraries, so you don't have to duplicate but you can easily accumulate stuff in that appdir that is easy to move to your server.
The qt plugin has binarties published, so you can just use that rather than building it from source. They use the same appdir style of bundling everything into an image, so you can just grab the binary, chmod it +x and use it.
13/13